It's all kind of baffling. We have decades of experience that tells us that writing secure software is very difficult and that patching insecure software is expensive, inefficient, and largely ineffective. So the response -- and not just in the auto industry -- is to constantly add more questionably necessary complex hardware and software (Why do I need digital air time pressure indicators that do not work properly to replace $2 mechanical pressure indicating Schraeder valve caps?) and then express surprise that the result is vulnerable to digital attack.
Folks. I don't know how to break this to you. The "solutions" that don't work on the internet, with financial stuff, with dating sites, etc probably aren't going to work in cars either..
What will work? Nothing most likely. But minimizing attack surfaces by air gapping systems that don't need to talk to one another, making ROMs read only with a physical programming switch, banishing anything that looks or works like javascript, abandoning the odd notion that over the air updates can't -- by accident or hijacking -- simultaneously brick millions of vehicles might help. The result would be clunky and sort of mid-20th centuryish. But it might be moderately secure.. And implementing it might free up resources to deal with the inevitable similar problems in the rest of the digital world.
Serious Question: Is it ever going to be possible to secure systems that allow firmware to be updated by a remote user?
Isn't it likely that at some point we're going to have to face up to the reality that many things we find to be extremely convenient simply aren't compatible with the notion of security?
Get mostly linux machines for the mainstream work, and get a few windows systems for the jobs that really need windows.
vnc seems to work acceptably to allow a unix machine to control a process running on a Windows XP machine. As does rdesktop I believe. I imagine that one or the other or something similar will work with a more modern (i.e. probably even more obtuse) Windows version. Files can be transferred with Samba.
That would be a pain to set up and to make cleanly accessible to an untrained user who is probably pretty overwhelmed with all the other stuff he or she is trying to learn. But it's probably technically feasible.
It isn't (and never was) a question of capabilities. It is a question of cost. Most decision makers at every level from individuals on up to CEOs view IT (correctly BTW) as an expense, not a corporate treasure. The IP6v train left the station without the capabilities required to make eventual I{Pv4 replacement cheap and easy -- backward capability and NAT. Lots of people tried to point out that was a mistake. It was done anyway, and the same folks that didn't understand why it was a mistake still don't seem to understand why it was a mistake.
Compared to the average business or public organization, our home setup here is not very complex at all. But we still have about two dozen devices whose software would need to be upgraded in order to change from IPv4. to IPv6. And we'd probably have to buy some new kit because some of the routers and software probably have flawed IPv6 implementations -- if they have IPv6 at all. And, of course our ISP is IPv4. Assuming they can/will deign to talk to us using IPv6 it's a safe bet that "upgrading" would cost us more time and money.
And what do we get from all that? IFAICS all we get is the capability to expose all the digital devices in the house to external hackers. Why would we want to do that? Much less spend time and money to do that?
It'll most likely be a long, long time before IPv6 completely replaces IPv4.
Codger's Law -- any programming scheme, no matter how simple and elegant the initial framework, will eventually be extended and improved into near total unusability.
So long as you remember that the M in HTML is "Markup", not "Layout". If it is important that page layout be "perfectly" preserved in the presentation, something else like pdf (Yechhh) might be a better choice.
Yes text handling for non-ascii characters can be surprisingly maddening to work with. (Wasn't UTF-8 supposed to fix that?). Problem is that wrapping txt in some more elaborate format like HTML often doesn't make the problem go away. With apologies to Jamie Zawinski It just means that now you have two problems.
Pretty much my thought. Use the simplest format that will do the job. It it's just prose, use txt. Does anyone seriously believe that One Day in the Life of Ivan Denisovitch is somehow enhanced by saving it as.doc or.pdf or.htm or god knows what else? If the text needs some bold and italics, use.txt with markdown. If it needs lots of markup, then something more elaborate -- preferably something with standards and a DTD or equivalent indicating what standard applies. If there are flat tables, use csv. Spreadsheets? Best use their native format (.ods,.xls, etc) I should think. Images and music? Not my area of expertise. I use jpeg and mp3 respectively for myself, but I wouldn't be at all surprised that there are better choices
It the risk of coming across as being really dense, what are people gong to make in this here space or shop or whatever? If they are just going to modify some ill designed plastic stuff, then a couple of Dremels, a selection of bits, eye protection, and a vice may be all they need. If, OTOH, they are going to build a CubeSat http://en.wikipedia.org/wiki/C... They possibly need some sophisticated metal working stuff and some basic electronic test equipment..
I'd start off by surveying the potential users if you can find any and see what they want to do that they can't do, and aren't doing, in their dorm rooms right now. You might also survey the teaching staff and see if any of them will actually send users to the "space" to do stuff somehow connected with the college's perceived educational mission.
All in all, two thousands years ago, in Greece, people were arguing if the world rests on the backs of three elephants or three whales, and assumed that the world is flat.
Actually, I think the Greeks pretty much agreed that the Earth is a sphere with a radius of about 6000 km (Erosthenes-roughly 240BC) What they were arguing about is whether it or the sun is the center of the universe (Aristarchus of Samos-about the same time)
(Don't you just love it when some bozo comes along and knitpicks your rhetoric?)
Actually, the chances of winning a lawsuit are probably pretty good although a cynic might suspect that the lawyers will be the big winners. One thing though. If there are sufficient stresses built up for a magnitude 7 earthquake, doesn't that suggest that there will eventually be a 7.1 or 7.2 or greater quake when nature decides in her own inimitable way to relieve the accumulated stresses without human help?
Think about it.
In the meantime one wonders what drillers are going to do with zillions of gallons of contaminated water. I'm confident they'll figure out something -- probably something that will appall environmentalists even further.
but take into consideration that the army has autonomous vehicles right now that drive offroad constantly.
Well, no. They don't seem to. They're talking about autonomous vehicles And there is at least one far enough along for photo shoots. http://rt.com/usa/driverless-a... But it's often a long way from capability demonstration to proven capability. Not to mention that there may be some significant differences between the appropriate method for an autonomous APC to deal with a couple of cows in the road and the same situation in a Fiat Panda.
> If you just encrypt the data before sending it to the cloud, nobody in their sane mind would waste resources decrypting it (specially for such low hanging fruits).
Same's true of an encrypted sd card or USB stick under the liner in the trunk of your car. And the data transfer rate to put it there is a lot higher than a typical internet connection.
> And early results will show reductions in vehicle fatalities...
And accidents in general. It's extremely unlikely that autonomous vehicles will travel over the speed limit (when the actually know what it is) follow too closely except in some unusual and hard to detect road/weather conditions, or fail to notice vehicles that have managed to find their way into "blind spots". There will still be accidents when front wheel bearings seize, etc. And initially, software and hardware bugs are going to kill and/or maim a few people.
The fact that courts will probably assign liability to the creator of bad code, is probably going to come as an unexpected surprise to a software industry that is used to blaming all their problems on user ineptitude.
No, I do not know what will happen to US police forces when traffic tickets cease to be a reliable source of revenue. I imagine they will think of something.
> Nice try, but we're already seeing it in consumer^Wautomotive-grade cars.
Might want to discuss OBD-II diagnostics with your mechanic. Be prepared to hear a LOT of profanity -- especially wrt On Board Vapor Recovery system "errors".
That said, the mechanical stuff generally is pretty reliable with a few notorious exceptions like GM's ignition switch problems. The software? It's not that complex I think. And it still sort of sucks much of the time.
The irony here, of course, is that you're the one assuming the programmers making these systems are egomaniacs who don't take any exceptional cases into account and never test for them.
You seem to assume that's not an accurate description of many programmers and even more of their managers. And in any cases, the bugs that one needs to worry about with physical devices like cars probably largely fall into the "Well shi.... Who could have guessed the damn thing might do that? catagory."
No reason that autonomous vehicles can't handle most unpaved roads eventually -- after decades of development and a lot of "incidents" -- some amusing, some tragic. And a LOT of lawsuits incidentally. Unpaved rural roads that are well maintained are fairly common in rural areas of the Eastern US. They really aren't much different from urban and suburban surface streets except for more washboarding, more washouts, more livestock in the road, no curbs, and perhaps fewer potholes. Poorly maintained unpaved roads are possibly going to lead to an issue of the car telling the occupants, "You want to continue down this purported 'road' feel free, but you're driving it, not me."
That said, I think fans of autonomous vehicles vastly underestimate the difficulty of navigating anything other than expressways or the variety of unusual and hazardous situations that need to be dealt with maybe once a year or once a decade even on expressways. 99.99% reliable and capable is great. But if the other.01% puts one in the hospital or morgue many folks are going to be a tough sell. Keep in the back of your mind that the automotive industry has yet to master even the comparatively simple problem of designing intelligent braking systems that work worth a damn on ice and snow even after decades of trying.
> It is going to get to the point where the only viable solution is a trusted sandbox. It will be something along the lines of a TPM chip to make sure that the OS image / boot loader has not been compromised, combined with a white listed set of applications and trusted content sources.
Maybe.. But seriously, it's not clear that this point that a trusted sandbox is actually achievable even in concept, much less in practice. Nor is it clear that anyone other than some classes of users who are forced by law or employer dictate to use a trusted system actually would do so. No or very restricted email, social networking, etc.
I think that the fact that banks and merchants appear to be unable to secure their transaction flows despite having strong financial incentives to do so ought to give one pause about the securability of anything -- or, at least, anything networked.
But you can do so much more sloppy programming with a more capable computer.
OTOH why does twice as much capability mean twice as much malware? Why not four times as much ? Or nine? or sixteen? Or maybe the malware to capability ratio is logarithmic
Barring some sort of radical change in priorities that causes the market to accept zero new features for, oh, a (human) generation or more, while vendors put out bugfix releases, 'winning' certainly isn't going to happen by doing conventional stuff; but harder.
Pretty much says it all. The population of exploitable software, design, and hardware bugs is clearly quite large, and is unlikely to decrease much as long as "capabilites" grow and grow and grow.
We live in a world dominated by wishful thinking then wonder why it is insecure.
Actually, I think that they don't use their PC much because it's slow, clunky, and doesn't work very well. The number one complaint I hear from those forced to use Windows is that it takes forever to boot.
Not that malware might not be number one if users had a clearer understanding of what it is.
I just happen to have a drawer full of Compaq Conturae. Neat little machines for their time. Haven't done anything with them for years except run automobile OBD diagnostics every year or two to find out why the Check Engine light is lit THIS time. And even that was superceded a few years ago by a USB OBD2 reader on a netbook. I pulled one of the Compaqs out and find that if has a Linksys EC2T Ethernet card in its' PCMCIA slot. I'm sure that WFWG 3.11 will do ethrnet file transfers given an appropriate driver. Maybe such a card can be found on eBay or some such. I think I recall that I had an early version of Slakware running on one of them at one point. No X windows -- too slow to be useful, but the console was OK.
Another possibility is to remove the hard drive and connect it to another machine. It's been a loooooong time, but ISTR that it's just a bog standard 2.5 inch IDE drive and I think they still make adapters that should work with it.. I seem to recall that access to the drive was not all that difficult, just removing a few screws and separating the case. But It's been 15 years or so and it might be harder than I remember.
Slashdot Mirror
It's all kind of baffling. We have decades of experience that tells us that writing secure software is very difficult and that patching insecure software is expensive, inefficient, and largely ineffective. So the response -- and not just in the auto industry -- is to constantly add more questionably necessary complex hardware and software (Why do I need digital air time pressure indicators that do not work properly to replace $2 mechanical pressure indicating Schraeder valve caps?) and then express surprise that the result is vulnerable to digital attack.
Folks. I don't know how to break this to you. The "solutions" that don't work on the internet, with financial stuff, with dating sites, etc probably aren't going to work in cars either..
What will work? Nothing most likely. But minimizing attack surfaces by air gapping systems that don't need to talk to one another, making ROMs read only with a physical programming switch, banishing anything that looks or works like javascript, abandoning the odd notion that over the air updates can't -- by accident or hijacking -- simultaneously brick millions of vehicles might help. The result would be clunky and sort of mid-20th centuryish. But it might be moderately secure.. And implementing it might free up resources to deal with the inevitable similar problems in the rest of the digital world.
Serious Question: Is it ever going to be possible to secure systems that allow firmware to be updated by a remote user?
Isn't it likely that at some point we're going to have to face up to the reality that many things we find to be extremely convenient simply aren't compatible with the notion of security?
vnc seems to work acceptably to allow a unix machine to control a process running on a Windows XP machine. As does rdesktop I believe. I imagine that one or the other or something similar will work with a more modern (i.e. probably even more obtuse) Windows version. Files can be transferred with Samba.
That would be a pain to set up and to make cleanly accessible to an untrained user who is probably pretty overwhelmed with all the other stuff he or she is trying to learn. But it's probably technically feasible.
A "safe" with a USB port? What could possibly go wrong?
It isn't (and never was) a question of capabilities. It is a question of cost. Most decision makers at every level from individuals on up to CEOs view IT (correctly BTW) as an expense, not a corporate treasure. The IP6v train left the station without the capabilities required to make eventual I{Pv4 replacement cheap and easy -- backward capability and NAT. Lots of people tried to point out that was a mistake. It was done anyway, and the same folks that didn't understand why it was a mistake still don't seem to understand why it was a mistake.
Compared to the average business or public organization, our home setup here is not very complex at all. But we still have about two dozen devices whose software would need to be upgraded in order to change from IPv4. to IPv6. And we'd probably have to buy some new kit because some of the routers and software probably have flawed IPv6 implementations -- if they have IPv6 at all. And, of course our ISP is IPv4. Assuming they can/will deign to talk to us using IPv6 it's a safe bet that "upgrading" would cost us more time and money.
And what do we get from all that? IFAICS all we get is the capability to expose all the digital devices in the house to external hackers. Why would we want to do that? Much less spend time and money to do that?
It'll most likely be a long, long time before IPv6 completely replaces IPv4.
Codger's Law -- any programming scheme, no matter how simple and elegant the initial framework, will eventually be extended and improved into near total unusability.
So long as you remember that the M in HTML is "Markup", not "Layout". If it is important that page layout be "perfectly" preserved in the presentation, something else like pdf (Yechhh) might be a better choice.
Yes text handling for non-ascii characters can be surprisingly maddening to work with. (Wasn't UTF-8 supposed to fix that?). Problem is that wrapping txt in some more elaborate format like HTML often doesn't make the problem go away. With apologies to Jamie Zawinski It just means that now you have two problems.
Pretty much my thought. Use the simplest format that will do the job. It it's just prose, use txt. Does anyone seriously believe that One Day in the Life of Ivan Denisovitch is somehow enhanced by saving it as .doc or .pdf or .htm or god knows what else? If the text needs some bold and italics, use .txt with markdown. If it needs lots of markup, then something more elaborate -- preferably something with standards and a DTD or equivalent indicating what standard applies. If there are flat tables, use csv. Spreadsheets? Best use their native format (.ods, .xls, etc) I should think. Images and music? Not my area of expertise. I use jpeg and mp3 respectively for myself, but I wouldn't be at all surprised that there are better choices
It the risk of coming across as being really dense, what are people gong to make in this here space or shop or whatever? If they are just going to modify some ill designed plastic stuff, then a couple of Dremels, a selection of bits, eye protection, and a vice may be all they need. If, OTOH, they are going to build a CubeSat http://en.wikipedia.org/wiki/C... They possibly need some sophisticated metal working stuff and some basic electronic test equipment..
I'd start off by surveying the potential users if you can find any and see what they want to do that they can't do, and aren't doing, in their dorm rooms right now. You might also survey the teaching staff and see if any of them will actually send users to the "space" to do stuff somehow connected with the college's perceived educational mission.
Actually, I think the Greeks pretty much agreed that the Earth is a sphere with a radius of about 6000 km (Erosthenes-roughly 240BC) What they were arguing about is whether it or the sun is the center of the universe (Aristarchus of Samos-about the same time)
(Don't you just love it when some bozo comes along and knitpicks your rhetoric?)
Actually, the chances of winning a lawsuit are probably pretty good although a cynic might suspect that the lawyers will be the big winners. One thing though. If there are sufficient stresses built up for a magnitude 7 earthquake, doesn't that suggest that there will eventually be a 7.1 or 7.2 or greater quake when nature decides in her own inimitable way to relieve the accumulated stresses without human help?
Think about it.
In the meantime one wonders what drillers are going to do with zillions of gallons of contaminated water. I'm confident they'll figure out something -- probably something that will appall environmentalists even further.
Well, no. They don't seem to. They're talking about autonomous vehicles And there is at least one far enough along for photo shoots. http://rt.com/usa/driverless-a... But it's often a long way from capability demonstration to proven capability. Not to mention that there may be some significant differences between the appropriate method for an autonomous APC to deal with a couple of cows in the road and the same situation in a Fiat Panda.
> If you just encrypt the data before sending it to the cloud, nobody in their sane mind would waste resources decrypting it (specially for such low hanging fruits).
Same's true of an encrypted sd card or USB stick under the liner in the trunk of your car. And the data transfer rate to put it there is a lot higher than a typical internet connection.
> And early results will show reductions in vehicle fatalities ...
And accidents in general. It's extremely unlikely that autonomous vehicles will travel over the speed limit (when the actually know what it is) follow too closely except in some unusual and hard to detect road/weather conditions, or fail to notice vehicles that have managed to find their way into "blind spots". There will still be accidents when front wheel bearings seize, etc. And initially, software and hardware bugs are going to kill and/or maim a few people.
The fact that courts will probably assign liability to the creator of bad code, is probably going to come as an unexpected surprise to a software industry that is used to blaming all their problems on user ineptitude.
No, I do not know what will happen to US police forces when traffic tickets cease to be a reliable source of revenue.
I imagine they will think of something.
> Nice try, but we're already seeing it in consumer^Wautomotive-grade cars.
Might want to discuss OBD-II diagnostics with your mechanic. Be prepared to hear a LOT of profanity -- especially wrt On Board Vapor Recovery system "errors".
That said, the mechanical stuff generally is pretty reliable with a few notorious exceptions like GM's ignition switch problems. The software? It's not that complex I think. And it still sort of sucks much of the time.
You seem to assume that's not an accurate description of many programmers and even more of their managers. And in any cases, the bugs that one needs to worry about with physical devices like cars probably largely fall into the "Well shi.... Who could have guessed the damn thing might do that? catagory."
No reason that autonomous vehicles can't handle most unpaved roads eventually -- after decades of development and a lot of "incidents" -- some amusing, some tragic. And a LOT of lawsuits incidentally. Unpaved rural roads that are well maintained are fairly common in rural areas of the Eastern US. They really aren't much different from urban and suburban surface streets except for more washboarding, more washouts, more livestock in the road, no curbs, and perhaps fewer potholes. Poorly maintained unpaved roads are possibly going to lead to an issue of the car telling the occupants, "You want to continue down this purported 'road' feel free, but you're driving it, not me."
That said, I think fans of autonomous vehicles vastly underestimate the difficulty of navigating anything other than expressways or the variety of unusual and hazardous situations that need to be dealt with maybe once a year or once a decade even on expressways. 99.99% reliable and capable is great. But if the other .01% puts one in the hospital or morgue many folks are going to be a tough sell. Keep in the back of your mind that the automotive industry has yet to master even the comparatively simple problem of designing intelligent braking systems that work worth a damn on ice and snow even after decades of trying.
> It is going to get to the point where the only viable solution is a trusted sandbox. It will be something along the lines of a TPM chip to make sure that the OS image / boot loader has not been compromised, combined with a white listed set of applications and trusted content sources.
Maybe .. But seriously, it's not clear that this point that a trusted sandbox is actually achievable even in concept, much less in practice. Nor is it clear that anyone other than some classes of users who are forced by law or employer dictate to use a trusted system actually would do so. No or very restricted email, social networking, etc.
I think that the fact that banks and merchants appear to be unable to secure their transaction flows despite having strong financial incentives to do so ought to give one pause about the securability of anything -- or, at least, anything networked.
But you can do so much more sloppy programming with a more capable computer.
OTOH why does twice as much capability mean twice as much malware? Why not four times as much ? Or nine? or sixteen? Or maybe the malware to capability ratio is logarithmic
I'm sorry. This is Slashdot so we'll be needing a car analogy.
Demolition Derby?
The Greeks won that particular arms race.
Yes, but they had to resort to social engineering.
Barring some sort of radical change in priorities that causes the market to accept zero new features for, oh, a (human) generation or more, while vendors put out bugfix releases, 'winning' certainly isn't going to happen by doing conventional stuff; but harder.
Pretty much says it all. The population of exploitable software, design, and hardware bugs is clearly quite large, and is unlikely to decrease much as long as "capabilites" grow and grow and grow.
We live in a world dominated by wishful thinking then wonder why it is insecure.
but don't use it much out of fear of malware
Actually, I think that they don't use their PC much because it's slow, clunky, and doesn't work very well. The number one complaint I hear from those forced to use Windows is that it takes forever to boot.
Not that malware might not be number one if users had a clearer understanding of what it is.
I just happen to have a drawer full of Compaq Conturae. Neat little machines for their time. Haven't done anything with them for years except run automobile OBD diagnostics every year or two to find out why the Check Engine light is lit THIS time. And even that was superceded a few years ago by a USB OBD2 reader on a netbook. I pulled one of the Compaqs out and find that if has a Linksys EC2T Ethernet card in its' PCMCIA slot. I'm sure that WFWG 3.11 will do ethrnet file transfers given an appropriate driver. Maybe such a card can be found on eBay or some such. I think I recall that I had an early version of Slakware running on one of them at one point. No X windows -- too slow to be useful, but the console was OK.
Another possibility is to remove the hard drive and connect it to another machine. It's been a loooooong time, but ISTR that it's just a bog standard 2.5 inch IDE drive and I think they still make adapters that should work with it.. I seem to recall that access to the drive was not all that difficult, just removing a few screws and separating the case. But It's been 15 years or so and it might be harder than I remember.