It's real! This single track is no longer used; there's a newer double track a tad south, that runs under the Sugar Bowl ski area. There are lots of freight and passenger trains.
What's amazing is that people are allowed to hike and drive up into the old tunnels, miles of tunnel, show shed, and occasional open stretches hugging the cliffs. No guard rails.
Is anybody capable of creating secure software?
Of course! But you have to set that as a goal to begin with! You can't "back-fill" security.
Is anybody capable of creating a reliable power supply?? Surely NOT if your goal at the outset is *inexpensive*, short time to market, planned replacements/upgrades, etc.
Most people are. Few people can create secure software, even when they try.
Really? Almost universally, the item that renders most of the devices that I've purchased "inoperational" is a power supply or power conditioning somewhere in the circuit.
Of course, the reason cited is "cost", expected product lifetime, etc.
Can we start applying the same excuses to software, too? I.e., "boss wanted to keep development costs low -- to keep *product* costs low" (just like saving a few pennies on a power supply amortized over a few million units??)
Tell people you value security, reliability, etc. and they will produce products that meet those goals. Instead, tell people you want a $30 DVD player and you'll end up with a device that will bearly survive its warranty period ("Hey, what did you expect for $30??")
Sure, you can buy the cheapest power supply around, and expect it to be junk. Probably by design.
Do you think that IE, or OSX, or Jeep software, or the software that runs the US government database, was done on the cheap?
"One U.S. official said the breach of data involving more than 4 million past and present federal workers was being investigated as a national security matter. That suggests authorities believe a nation was behind it rather than a more loosely organized gang of cybercriminals. The official was not authorized to discuss an ongoing investigation and spoke only on condition of anonymity.
The breach was an embarrassing showing for the U.S. government's
supposed to detect unusual Internet traffic that might reflect hacking attempts or stolen data being transmitted outside the government."
So, the power supplies in the $200 monitors, $2,000 televisions, $500 printers, $100 DVD players, etc. are ALL junk? I guess the folks designing reliable power supplies just don't cater to the same markets as the folks who expect ALL software to be "bug free", reliable, secure, etc.
How many millions of dollars of failed power supplies are discarded each year? Forget the associated costs of the devices that they were powering (and part of) at the time! But, those are "acceptable losses" -- expectations for hardware are that it *will* need to be replaced due to failure. Yet, software is supposed to magically be perfect -- else the monies spent on it are considered waste (but the dollars spent building those broken power supplies aren't?)
I think you sorely underestimate the complexity of even the most trivial piece of software.
Next time you want to design a piece of hardware, start by growing some silicon wafers. Tell me how long you expect the design process to take. And, how reliable you expect the resulting product to be.
Hardware is relatively easy to create. Look at your "standard components". Two and three terminal devices. Easily characterized. Even highly integrated devices are easily characterized.
Sort of like an *opcode*: take one of these 4 billion discrete values, combine it with another of these 4 billion discrete values and obtain exactly one of a resulting N billion values. (amps, volts, etc.). Put a few MILLION of these components together in a time-significant sequence and you've got a reasonably small (by today's standards) piece of code.
Put a few million GATES together and you've got a processor. Not the sort of thing you knock out in a few weeks on a lab bench. And, most definitely not the sort of thing you can completely and exhaustively characterize (like your few hundred component power supply).
Even the more highly integrated hardware components are far easier to characterize than the most widely used "software components":
- How big is the executable? (on which processor? what compiler options?)
- How much data memory does it require? (for what set of inputs??)
- What is the maximum stack penetration? (for what conditions?)
- How long does it take to execute? (in what environment?)
- What is the expected "result"?
[Try this exercise with something as simple as a sort algorithm. Better yet, repeat it for the popular sort algorithms -- so a potential consumer of your algorithm would be able to choose from among them in by examining a parameterized "selection table" in a "software data book"]Yet, the software is expected to perform reliably *forever* -- else you get folks complaining that it's buggy, insecure, unreliable. Yet, for a power supply to crap out after a few (tens??) thousand hours is "Wow, look how reliable that *WAS* (past tense)!"
When people place value on security and reliability in software, they
*get* secure and reliable software (been there, done that, T-shirt...). When people give LIP SERVICE to those things, they invariably show their true colors before the rubber hits the road and decide cost, time to market, etc. are far more "important" -- "We'll fix it later".
In Kalifornia? No Prop-65 warning either?
My wife drives a couple of year old Mustang Convertible ('14 model). Nice car. The instruments are *supposed* to be retro. The entire car is supposed to be retro '60s. That's the whole point.
The MY'15 is an entirely new car from the ground up (but looks quite similar) and by all accounts are *really* nice drive.
If all car companies did that, you wouldn't drive anything. All rental cars are the pits.
Yep. Seems to be a common theme with all commercial software. Software development has entered the stone age (maybe).
In theory, no. The "Infotainment" network is supposed to be isolated from the "safety critical" networks. In reality, theory and reality don't match so well (as we've seen in the news recently).
...and Google cars don't scare you?
The answer to your question is simple; "consumer electronics". Yes, it's all junk. It's not designed to last (or perhaps even "designed not to last").
And TCP/IP is *not* a reliable protocol. It guarantees not to deliver data out of order, but it doesn't guarantee to deliver anything within any fixed time window, or to report failure in any time window either.
We had more guard rails in Louisiana, which is absolutely flat, than we have in California, where a second of inattention will toss you 400 feet down into a forest or into the ocean.
We use MeanWell open-frame PFC switchers for something absurd like 20 cents per watt. And Phihong and Samsung wall-warts for $5 to $10 each. They are great.
You can get cheaper stuff if you really want it. The low end warts and USB supplies can't deliver 50% of the nameplate current.
The problem is that it's so complex that nobody can understand it.
Exactly. Most hardware designs don't exceed the definition of "too big to fit in a single braincase" (complexity). OTOH, many software designs easily exceed that!
Try building a piece of hardware that will sort an undefined number of inputs by value. Or, sum a set of values -- each having 200+dB of dynamic range. Make sure it works over the entire operating temperature range without degradation. Expect a customer to requests along the lines of "sum only the values that are multiples of 3 (unless they are also multiples of 5!), after discarding the highest and lowest" -- and to support that retrofit IN THE FIELD... all without disturbing any of the gizmos that are presently "wired" to the circuit. And, marketing has promised it by 5:00PM tomorrow!
If confronted with this sort of request, you'd laugh and, if the client/customer was serious, quote some ridiculous (from the standpoint of the client!) price and delivery schedule. But, software is magically expected to adapt -- without concern or consideration for how many initial assumptions have been violated by that request! And, as there is no "visible" change in the deliverables, any significant change in price is considered gluttony!
[We think nothing about buying a "cheap" TV -- and discarding it when it ultimately fails. But, is there a shelf for "cheap" pieces of software? E.g., those where you don't really care if their addition/subtraction results are correct?? Or, do you expect to get "top shelf quality" at "clearance sale" prices??]
I'd say yes, that some people are. But it takes extraordinary care, and a recognition that things must be kept simple, so that all the possible ramifications can be anticipated.
In practice this means that programs that, by their nature, cannot be kept simple, and which have access to critical systems[*], must not receive data from any potentially insecure source.
Some manufacturers do seem to understand that. Too many either do not, or just don't care.
[*] In this context, "access to" means "not proven not to have access to."Sylvia.
The problem is that in complex systems, like internet-connected things, people don't write all their own code. They incorporate all sorts of junk from OSs, libraries, compilers, whatever.
It's not too difficult to write secure and bug-free embedded apps, even RTOSs, if one good programmer can do the entire project. But nobody can make millions of lines of code reliable.
The critical stuff in a vehicle should be essentially bare-metal, and its communications to other processors should be serial or SPI or some non-TCP/IP sort of basic thing. Giving an engine control computer an IP address and connecting it to the wireless world is crazy.
People have claimed that they can hack an aircraft FADEC from a passenger seat. I sure hope that's not true.
On Thu, 23 Jul 2015 20:57:02 -0700, John Larkin Gave us:
If you think flight control computers are hackable via passenger in-flight wireless networks you are nuts and so are the hackers who claim they can. They are not merely "two different network segments on the same network", they are 100% completely different networks, and TCP/IP is not even involved. Most are ARINC, which no tcp/ip dopehead is going to be hacking from his passenger seat.. They are typically CLOSED, hard wired systems. Doh!
Despite the fears pilots and airlines, etc. show, one cannot even disrupt such systems with devices using RF means, such as explicit attempts to jam or access.
All this "turn off all devices until airborne" crap is nonsense.
Short of a major EMP pulse it ain't happening ("it" being disruption or takeover control).
Typically, the passenger entertainment system includes a display with aircraft position, altitude and speed. The most obvious source of the data for that is the aircraft's navigation system, which implies a communications link.
Such a link can be made indisputably one-way, and should be in this application, but absent a clear description of the actual mechanism used, we have to take it on trust that the implementation really is one-way.
Sylvia.
There's nothing wrong with component reuse. The problem lies with components that weren't designed with security, reliability, robustness, accuracy, etc. in mind. Would you use a semiconductor in a particular set of environmental conditions if you didn't KNOW that the device was designed for use *in* those conditions? At the very least, you'd look at the datasheet and see what "typ" performance is specified for your conditions. If you're a more robust developer, you'd also want to see worst case numbers (barring that, something that quantifies the distribution of values
*around* "typ").Show me *any* of those parameters for *any* piece of software! :>
Reliability and security are different animals entirely. An application can be VERY reliable -- and VERY insecure.
You can take measures during development to increase reliability, accuracy/correctness and/or security. Even things as simple as "best practices" can make a remarkable difference in each of these aspects of a design/implementation.
You use similar "best practices" when designing hardware. E.g., derating components, shake 'n' bake, etc.
But, too many software development and execution environments do not address these. Or, try to address them as afterthoughts. As if you can buy a big lock to put on the front door of your house to keep it "secure" -- while ignoring the fact that a large percentage of the exterior walls is *glass*!
Coding on bare metal will probably result in a more insecure, less reliable and more costly (to develop) implementation. The whole point of an operating system is to give you an enhanced execution environment that increases your chances of producing secure, reliable and cost-effective implementations.
In my current project, I put lots of "mechanism" into the OS and "support services". So, applications don't need to reimplement things that might be commonly used (e.g., BigRational numerics) as they stand a greater chance of implementing those things incorrectly -- or, cutting corners as an expedient (e.g., "I only need 72bit Rationals") and later erroneously reapplying those "incomplete implementations".
[Great example of this: see how many buggy floating point libraries you can encounter over the years as folks "rolled their own" before these sorts of things were readily available/standardized. Heck, it's just simple arithmetic operations -- how could they possibly get them *wrong*?? :> ]I provide individual protected execution spaces for each "job" so *you* can't "accidentally" alter or corrupt *my* data -- or, my execution. *Your* bugs affect *you* and no one else!
I provide authentication and authorization mechanisms for fine-grained resource control. E.g., I can let *you* "mute" the audio but never "increase" or "decrease" it. I can let you *set* a value but prevent you from *seeing* its current setting. At the same time, let someone else *see* it but not *set* it.
While none of these things GUARANTEE that the code will be more accurate/correct, reliable or secure, they provide a convenient framework for *cooperative* developers to do the sorts of things that they need to do and reap the benefits of the underlying mechanisms to make their lives easier *and* their code more predictable/inspectible.
[E.g., you could choose to share a value with through some ad hoc mechanism. But, then *you* have to build that mechanism. In doing so, it makes it harder for a code audit to see where you may be introducing a vulnerability. OTOH, if it is EASIER for you to just use some preexisting mechanism to share that value, then your sharing is more readily identified in the codebase. And, the criteria that you have chosen to apply to that sharing are more readily identified: "Why are you sharing this with EVERYONE? Don't you just want to share it with Foo?" (unnecessary sharing leads to exploits) "And, why, exactly, does Foo need to see this? Can't Foo do it's job *without* it??"]Silly boy. Why would you think it hasn't happened? People have hacked pacemakers, insulin pumps, cars, gaming device$, pay phones, banks, electronics/computer companies, etc. A little time with your favorite search engine should turn up enough documentation to get you thinking...
Note that a "hack" need not mean something was "commandeered". Rather, it represents an unexpected and undesired interference with the intended, normal operation of the device/system.
In the case of the hacked Jeep, you needn't be able to steer, accelerate, brake, etc. in order to have hacked it. Simply interfering with its ability to operate as intended constitutes a hack. E.g., jabbering on the interconnect network -- even if everything you are "saying" is total jibberish -- could easily prevent the system from operating as required. Whether the system handles that assault gracefully or catastrophically is up to the implementors.
When I designed the comms for my automation system, it would have been incredibly naive to think that someone wouldn't elect to "hack" it -- to gain entry to the residence, to "spy" on what I was doing within, to track my TV/radio habits (valuable to a commercial entity -- especially if they could be gleaned without criminal activity!), etc.
And, it's also possible that someone might want to simply *disrupt* the system's proper functioning. Either for some particular exploit or simply to deny those services to the occupants. Imagine the opportunities when accessing that system is possible remotely! (which greatly increases its value to the *owner* -- at the expense of downside hacking risk!)
While there is only *one* such system, the risk is effectively non-existent -- a special case of security by obscurity. OTOH, if I expect others to build upon my efforts -- opening up the design in intricate detail to all sorts of potential hacking experiments -- then failing to address those issues UP FRONT means they will NEVER be addressed, adequately.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required