Recent Features
| |||||||||||||
The embedded long-term support initiativeThe embedded long-term support initiativePosted Oct 30, 2011 19:48 UTC (Sun) by epa (subscriber, #39769)In reply to: The embedded long-term support initiative by kragilkragil2 Parent article: The embedded long-term support initiative
Surely the answer is to stop relying on updates and patching to fix security holes after the fact. The software needs to be designed so that you know with reasonable certainty that it is secure as shipped, and further measures need to be in place to make sure that even if there is a vulnerability in one part of the system, it doesn't matter much. We have grown inured to releasing software with serious flaws* and patching it later. This would not be acceptable in any other industry. Yes, recalls and field modifications do happen, but they are the exception and considered an embarassment for the company that shipped a faulty product.
* For the sake of argument, anything that lets an attacker get your credit card number without lots of social engineering may be considered a serious flaw.
(Log in to post comments)
The embedded long-term support initiative Posted Oct 30, 2011 22:24 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
I struggle to imagine how any other industries could begin to compare. We're not talking about something like the lever or wheel. Programmable computers escape our ability to reliably understand what they're doing long before the scale where they're of any use to us, as Radó noticed.
You can try Formal Methods. If you're building a bomb, or maybe the core control systems for a nuclear reactor, you might persuade someone to pay for that. For their extra money, they will get something far harder to use and far less capable than everything else in the world, but very slightly more reliable.
The embedded long-term support initiative Posted Oct 31, 2011 16:11 UTC (Mon) by zlynx (subscriber, #2285) [Link]
Formal Methods.
Hahah.
With those, all you have done is written the program twice. Once in the language and once in the formal verification.
(Almost) all of the mistakes it is possible to make while programming are possible to duplicate in the formal methods.
So if you have a security flaw where you have forgotten to specify that Method A must not be called before passing Security Check A, or if the specification does not spell out that calling Method B invalidates the current security state. That flaw will exist no matter how thorough the formal methods are.
The embedded long-term support initiative Posted Nov 1, 2011 11:57 UTC (Tue) by dps (subscriber, #5725) [Link]
Formal methods are much more reliable than most programming languages. Just writing an unambiguous specifications helps. Formal methods also allow non-negotiable proof that a proposed solution meets the specification.
You can also prove things like *any* network of the stated components with an infinitely readable external input is deadlock free. I am not aware of any programming language that can do that.
In generally the experience is that using formal methods makes the initial phases longer and the final phases shorter, partly because a lot of problems and discovered sooner. Moves like only proving critical safety properties or analysing a high level design are popular.
As with any tool formal methods can be misused. I not only know formal methods but believe I have the taste to know when *not* to apply them.
Secure Software and Formal Methods Posted Nov 2, 2011 11:18 UTC (Wed) by abacus (guest, #49001) [Link] As far as I know formal methods are fine for functional specifications. I'm still waiting for a formal specification of a secure operating system though. See e.g. Gerwin Klein e.a., seL4: formal verification of an operating-system kernel, Communications of the ACM, Volume 53 Issue 6, June 2010.
Secure Software and Formal Methods Posted Nov 2, 2011 17:33 UTC (Wed) by zlynx (subscriber, #2285) [Link]
My complaint about formal methods is that they aren't any kind of cure-all. They rely on the specifications being complete and that the specifications are correctly translated into the formal verification method.
In almost all programming, the specifications are incomplete or incorrect. Programmers, even without realizing what they are doing, fill in the gaps in incomplete specifications and may not even realize the specification was missing information.
Many bugs are caused by programmers on each side of an interface assuming different things about the specification. An example of this is the POSIX select() timeout parameter.
To fully specify the behavior of a system under all conditions is in my opinion, as prone to oversights and misunderstanding (aka bugs) as writing the program itself in assembly or C. (Well, you can make a lot more typo type mistakes writing in C, but I think it holds for logic errors.)
Reading through some of that seL4 paper you linked, I see they had to make about 300 changes in the spec during the process. In other words, they had to debug it. I wonder how they know if they found all the problems in their spec?
Who will pay for it? Posted Oct 31, 2011 7:59 UTC (Mon) by khim (subscriber, #9252) [Link] Surely the answer is to stop relying on updates and patching to fix security holes after the fact. I doubt it. The software needs to be designed so that you know with reasonable certainty that it is secure as shipped, and further measures need to be in place to make sure that even if there is a vulnerability in one part of the system, it doesn't matter much. Do you propose a new law? What measures do you propose to make sure software development will not move to other, more liberal, countries?
Because without government mandate any company which will try this approach will just go bancrupt (by the time it'll release anything market will move to the "next big thing") so you'll need something big to make it happen. Do you really believe bureaucracy struggles over such mandates (this what will actually happen, I doubt quiality of the software itself will grow all that much) will actually make your life easier or better? This would not be acceptable in any other industry. Are you sure? From what I'm seeing other industries view this as a problem not as an achievement and move to "built-in computer with updates" model where they can. Sure, centuries-old industries are too conservative to eploy such ideas, but other, newer, industries... mobile phones, TV sets, blu-ray players and so on: they all switched from "what you buy is what you'll use till device will die" to "we'll fix any bugs later" model - and I'm sure other industries will follow. Yes, recalls and field modifications do happen, but they are the exception and considered an embarassment for the company that shipped a faulty product. They were exceptions and were considered as embarassment because they severely affected the bottom line. Now, when they are cheap... situation is changing. Sure, we'll not see upgradeable car computers any time soon (because cars have a lot of legal requirements around them), but "entertainment centers" in cars soon will surely follow the same model. Actually they were replaceable for a very long time so you can view them as precursors of today's "ship then fix" model...
Who will pay for it? Posted Oct 31, 2011 15:19 UTC (Mon) by epa (subscriber, #39769) [Link]
Relying on updates to fix security holes does not work! It hasn't worked to keep us secure over the past twenty years, what reason is there to suppose it will work for the next twenty?
You mention mobile phones, Blu-ray players and so on. Those are all parts of the software industry. When I said 'this would not be acceptable in any other industry' I was referring to industries other than software. It is not good enough to put up an unsound building and return to fix it later when flaws are discovered. (It does happen, but is rare and shaming for the architects and builders involved.) You can't sell a desk lamp with unsafe wiring and rely on asking people to take it back to the store later. Only in the software industry do we try to get away with such practices. And as you say, the market usually tolerates it.
Who will pay for it? Posted Oct 31, 2011 16:38 UTC (Mon) by mpr22 (subscriber, #60784) [Link] In the building case: Correctness is feasible to achieve and validate, and the cost of remedying errors is relatively large. In the desk lamp case: Correctness is not merely feasible but trivial to achieve and validate. Software that does what there is currently perceived to be a demand for often lies somewhere between insanely hard and mathematically impossible to achieve and validate correctness of. The cost of remedying an error, on the other hand, is not strongly related to the severity of its consequences. Many disastrous software errors turn out to have trivial fixes. (And, of course, even if your software is provable, all you can prove is that it conforms to the provided specification. Proving that the specification is a correct statement of the requirements, or that the requirements were well-formed in the first place, is a separate problem.)
What are you talking about? Posted Oct 31, 2011 16:39 UTC (Mon) by khim (subscriber, #9252) [Link] Relying on updates to fix security holes does not work! On the contrary: it works very well indeed. The companies who use this approach survive and thrive. The companies who lost the wind and tried to fix all the bugs before shipment are history. You mention mobile phones, Blu-ray players and so on. Yup. Those are all parts of the software industry. Not even close. First mobile network started operating back in 1979, it was analogue and had nothing to do with software. First LD player was on sale year before that - and Bly-ray is it's direct descendant (from end-user POV). And first TVs were created even earlier: it was introduced back in 1928 and most definitely had nothing to do with software. Only in the software industry do we try to get away with such practices. Again: not true at all. Lots of industries use this approach too: mobile phones, credit cards, etc. Initially they had pathetic security but since they were convenient they were used anyway. Later, when frauds become a problem additional layers of security were added. The same happened with printed banknotes few centuries before. You can go back few thousands years (when first stamps and other similar tools were invented) - and see the very same picture. Again: special inks, papers and procedure and so on followed, not preceded. In fact where information is exchanged "rely on updates to fix security holes" is typical approach, not an exception. The only thing software introduced is "fast" updates. When you introduce new, more protected, banknote you must to this in slow, very spread-out manner. But when new software is created to patch vulnerability... you can push it in hurry. So no, I don't believe in "fix all the bugs before shipment" approach. It failed us for thousands of years - why do you think it can be fixed now?
Who will pay for it? Posted Oct 31, 2011 16:58 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
But we aren't talking about unsafe wiring in a desk lamp. Even if we were I'd argue that spending two hours travelling on the bus with a microwave (it caught fire spontaneously after ~8 months use) to get it replaced was a lot more hassle than any software update I've ever undertaken.
Your building example was better. But in fact it's completely routine to "snag" large office or industrial buildings.
When I helped take possession of a four story building in 1998 we were all issued with a sheet of orange stickers labelled "snag". Each problem we discovered was to be marked with a label, and added to a list maintained by the liaison to the building contractor. Some problems were corrected in a few days to our satisfaction, as well as if they'd been corrected during construction. Many were "bodged" so that they met the strict letter of the requirements, but were not really adequate (e.g. it's much cheaper to fiddle with the hinges on a door to make it close, for a few days until it settles again, than to buy and install a new door which fits properly). A few simply couldn't be fixed at all, no way around it without tearing down the building and beginning anew. Some orange stickers for those last problems remained as visible sores on the pristine new building until their adhesive failed years later.
If we added to the "snags" every conceivable way a resourceful and determined attacker could get into the building, we'd never have finished. What if they just drive a truck through the large glass frontage? What if they tailgate a legitimate employee? What if they pay someone to pull the fire alarm, dress as firemen, and just walk in?
Who will pay for it? Posted Nov 1, 2011 2:02 UTC (Tue) by foom (subscriber, #14868) [Link]
> It is not good enough to put up an unsound building and return to fix it later when flaws are discovered. (It does happen, but is rare and shaming for the architects and builders involved.)
On the contrary, putting up a building with serious "bugs" is exceedingly common. Where it matters most (building will fall down), extra care is taken to make sure it won't fail in that way, but, for all the other ways a building can be broken, it's quite common for a new building to in fact *be* broken in all of those ways.
E.g. leaking excessive amounts of water, light switches are in stupid places that don't make any sense, HVAC doesn't work right (hot/cold areas), architect decided not to put stairwells in elevator lobby (but rather halfway across the building in a supposed-to-be-locked area), so it turns out it's illegal to actually lock the entrance to the floor from the (public) elevator lobby, etc...
Who will pay for it? Posted Nov 2, 2011 8:15 UTC (Wed) by ekj (guest, #1524) [Link]
Writing bug-free software, does not work. As in, literally nobody has figured out how to do it, not even with near-infinite budgets for near-trivial computations.
Even those situations where we use the very strictest of quality-controls, and as a result end up paying orders of magnitude more than we would with "normal" software, we still get banal, -stupid- bugs like the Mars Climate Orbiter doing lithobraking due to one software-module using imperial units rather than metric like the rest of the software. (i.e. bugs not unlike those typical of normal off-the-shelf software)
In most lines of bussiness, simply *trying* to do software like that, would guarantee bankruptcy. There's a reason things are done the way things are done.
Who will pay for it? Posted Nov 3, 2011 9:53 UTC (Thu) by jschrod (subscriber, #1646) [Link]
> It is not good enough to put up an unsound building and return to fix it
> later when flaws are discovered. (It does happen, but is rare and shaming > for the architects and builders involved.)
I wish you lots of luck if/when you'll build your first house and that fantasy will be rather rudely destroyed.
Who will pay for it? Posted Oct 31, 2011 15:22 UTC (Mon) by epa (subscriber, #39769) [Link]
...and obviously, an entertainment centre that has bugs is fine, because it is not safety critical and cannot be used to steal money from you. My point is that things which are important must be held to a higher standard than that used for video games.
Who will pay for it? Posted Oct 31, 2011 15:35 UTC (Mon) by KSteffensen (subscriber, #68295) [Link]
An entertainment center used to show movies from some Netflix-like service could conceivably hold credit card information. so even things that don't immediately seem critical might be.
And some of us certainly wouldn't mind video games being held to a higher standard than what is currently the case.
Actually it CAN steal money from you - and that's the point Posted Oct 31, 2011 16:48 UTC (Mon) by khim (subscriber, #9252) [Link] ...and obviously, an entertainment centre that has bugs is fine, because it is not safety critical and cannot be used to steal money from you.... It can be used for that - and that's the point. Money themselves (coins and banknotes) were one of the first objects which employed "security updates" in it's design. "Security updates" are not something invented with software - on the contrary, they have centuries long history! And yes, they worked. Frauds happened all the time, but as long as they were rare enough "security patches" worked. They worked for so long - why do you think tomorrow everything will suddenly collapse? What exactly changed today?
|
|||||||||||||