On 7/23/2015 4:49 AM, Robert Wessel wrote:> On Wed, 22 Jul 2015 23:20:33 -0400, rickman <gnuarm@gmail.com> wrote: > >> On 7/22/2015 10:49 PM, Don Y wrote: >>> On 7/22/2015 3:30 PM, lasselangwadtchristensen@gmail.com wrote: >>>> Den onsdag den 22. juli 2015 kl. 00.22.18 UTC+2 skrev Don Y: >>>>> On 7/21/2015 2:35 PM, Ian Yellowley wrote: >>>>> >>>>>> I wonder why there should be any connection between these networks, I >>>>>> can see consolidation of steering, suspension and braking info for >>>>>> stability but the rest??? There would seem to be huge differences in >>>>>> required bandwidth, latency and reliability so is there a cost >>>>>> saving? I >>>>>> was involved in the design of steer by wire systems many years ago and >>>>>> the extent to which we went to provide reliability, multiple layers of >>>>>> redundancy and isolation from other systems were fairly extreme. This >>>>>> was in a University lab...I would expect at least that from a >>>>>> commercial >>>>>> product. >>>>> >>>>> From the (limited) exposure I've had to automotive control systems, >>>>> there >>>>> doesn't seem to be a cohesive, integrated "system design" at work. >>>>> Instead, there are all these little islands of control that are hacked >>>>> together and "integrated" after-the-fact. >>>>> >>>>> [Often, individual subsystems are farmed out to third parties. E.g., >>>>> you >>>>> can bet that the auto manufacturer doesn't design the navigation system, >>>>> entertainment system, security system -- perhaps not even the engine >>>>> control system itself!] >>>>> >>>>> E.g., why would the ECU need to talk to anything other than the >>>>> *engine*? >>>>> "Ah, but we can tell the air conditioning compressor to disengage >>>>> when we >>>>> are calling for extra demand from the engine! So, let the *engine* tell >>>>> the air conditioner to 'pause' -- instead of having some higher level of >>>>> integration impose those rules. Likewise, let the tranny controller >>>>> tell >>>>> the door locks to engage when the vehicle is put in gear (or, when the >>>>> wheels attain a certain speed). >>>> >>>> afaiu from a guy I know that works a lot with car electronics as in >>>> building >>>> ECUs, gearbox controllers and integrating them with the different >>>> system in >>>> a number of different cars, most of the systems are stand alone and >>>> mostly >>>> listen to each other, i.e. the ECU does nothing but run the engine and >>>> broadcast what it is doing, ditto for all the other systems >>>> >>>> so if the doorlocks see the tranny broadcasting a speed over x it can >>>> decide to lock the doors, if the AC see the engine broadcast a load >>>> over x >>>> it can decide to pause, if the ECU see the ABS module broadcast >>>> wheelspeeds >>>> that indicate wheelspin it can turn down the power >>>> >>>> I guess it is similar to the unix philosophy, do one thing and do it well >>> >>> Modern cars are more highly (functionally) integrated. >>> >>> There is little inherent in the protocols that directly supports >>> authentication. E.g., a node has no *proof* that a message/datum >>> actually originated from a node that is *intended* to source messages >>> of that type. So, the "radio link" -- once hacked -- can *forge* a >>> message indicating the engine speed is X or the shift lever has been >>> placed in 'R' or... >> >> Only if the radio link has access to the bus for the engine and >> transmission. It is a simple matter to maintain adequate separation >> between the core functions and the peripheral functions. > > > There are/will be inevitable points of intersection. Things like the > primary display will need to be attached to both the entertainment > system and the more critical car functions. The engine and nav system > will need to send messages to the main display and audio system, the > main display will configure drive system parameters ("teenager mode", > for example). What about the need for your car's crash safety system > to chat with the cellular radio in the case of a crash? > > And no, demanding separate displays and whatnot will never fly.Why not? If that is what safety requires, that is how it will be done. That is why the brakes are split into two circuits. It doesn't require "two" displays. It only requires that the engine speed and car speed are reported through separate electronics in the display. I know my car does that anyway... because it costs less.> So it's not ever going to be quite a simple matter of hard physical > separation between the critical and non-critical systems. More likely > a node serving a firewall/gateway function between otherwise > segregated systems makes sense. Rather than trying to implement > security in hundreds of different nodes (maintained by a similar > number of teams generally not communicating well with each other), > concentrate (most) of it in the firewall node.If you need security, you do what it takes for security. Two buses are not a problem. Yes, it's that simple. -- Rick
Semi-OT: Hackers Remotely Kill a Jeep on the Highway
Started by ●July 21, 2015
Reply by ●July 23, 20152015-07-23
Reply by ●July 23, 20152015-07-23
On 7/23/2015 6:26 AM, Don Y wrote:> On 7/23/2015 1:49 AM, Robert Wessel wrote: >> On Wed, 22 Jul 2015 23:20:33 -0400, rickman <gnuarm@gmail.com> wrote: >> >>> On 7/22/2015 10:49 PM, Don Y wrote: >>>> On 7/22/2015 3:30 PM, lasselangwadtchristensen@gmail.com wrote: >>>>> Den onsdag den 22. juli 2015 kl. 00.22.18 UTC+2 skrev Don Y: >>>>>> On 7/21/2015 2:35 PM, Ian Yellowley wrote: >>>>>> >>>>>>> I wonder why there should be any connection between these >>>>>>> networks, I >>>>>>> can see consolidation of steering, suspension and braking info for >>>>>>> stability but the rest??? There would seem to be huge differences in >>>>>>> required bandwidth, latency and reliability so is there a cost >>>>>>> saving? I >>>>>>> was involved in the design of steer by wire systems many years >>>>>>> ago and >>>>>>> the extent to which we went to provide reliability, multiple >>>>>>> layers of >>>>>>> redundancy and isolation from other systems were fairly extreme. >>>>>>> This >>>>>>> was in a University lab...I would expect at least that from a >>>>>>> commercial >>>>>>> product. >>>>>> >>>>>> From the (limited) exposure I've had to automotive control systems, >>>>>> there >>>>>> doesn't seem to be a cohesive, integrated "system design" at work. >>>>>> Instead, there are all these little islands of control that are >>>>>> hacked >>>>>> together and "integrated" after-the-fact. >>>>>> >>>>>> [Often, individual subsystems are farmed out to third parties. E.g., >>>>>> you >>>>>> can bet that the auto manufacturer doesn't design the navigation >>>>>> system, >>>>>> entertainment system, security system -- perhaps not even the engine >>>>>> control system itself!] >>>>>> >>>>>> E.g., why would the ECU need to talk to anything other than the >>>>>> *engine*? >>>>>> "Ah, but we can tell the air conditioning compressor to disengage >>>>>> when we >>>>>> are calling for extra demand from the engine! So, let the >>>>>> *engine* tell >>>>>> the air conditioner to 'pause' -- instead of having some higher >>>>>> level of >>>>>> integration impose those rules. Likewise, let the tranny controller >>>>>> tell >>>>>> the door locks to engage when the vehicle is put in gear (or, when >>>>>> the >>>>>> wheels attain a certain speed). >>>>> >>>>> afaiu from a guy I know that works a lot with car electronics as in >>>>> building >>>>> ECUs, gearbox controllers and integrating them with the different >>>>> system in >>>>> a number of different cars, most of the systems are stand alone and >>>>> mostly >>>>> listen to each other, i.e. the ECU does nothing but run the engine and >>>>> broadcast what it is doing, ditto for all the other systems >>>>> >>>>> so if the doorlocks see the tranny broadcasting a speed over x it can >>>>> decide to lock the doors, if the AC see the engine broadcast a load >>>>> over x >>>>> it can decide to pause, if the ECU see the ABS module broadcast >>>>> wheelspeeds >>>>> that indicate wheelspin it can turn down the power >>>>> >>>>> I guess it is similar to the unix philosophy, do one thing and do >>>>> it well >>>> >>>> Modern cars are more highly (functionally) integrated. >>>> >>>> There is little inherent in the protocols that directly supports >>>> authentication. E.g., a node has no *proof* that a message/datum >>>> actually originated from a node that is *intended* to source messages >>>> of that type. So, the "radio link" -- once hacked -- can *forge* a >>>> message indicating the engine speed is X or the shift lever has been >>>> placed in 'R' or... >>> >>> Only if the radio link has access to the bus for the engine and >>> transmission. It is a simple matter to maintain adequate separation >>> between the core functions and the peripheral functions. >> >> There are/will be inevitable points of intersection. Things like the >> primary display will need to be attached to both the entertainment >> system and the more critical car functions. The engine and nav system >> will need to send messages to the main display and audio system, the >> main display will configure drive system parameters ("teenager mode", >> for example). What about the need for your car's crash safety system >> to chat with the cellular radio in the case of a crash? > > Exactly. Even if a "compromised" node does not have direct *physical* > access to a "special" bus, the fact that the compromised node can > effortlessly masquerade as ANY node on the bus(ses) to which it has > direct contact means any other gateway/bridge nodes *will* propagate > forged messages that it generates *to* that "other bus" AS IF the > messages were created by the genuine node instead.That is based on the assumption that there are messages that can travel from the insecure bus to the secure bus. Obviously that has to be prevented in all cases.> This also assumes those gateway nodes are smart enough to recognize > *specific* traffic on "bus #1" as only legitimate *on* bus #1. I.e., > if a node on bus #1 forges a message that a node on bus #2 would > normally generate, the gateway *may* be naive enough to transport the > message across the protection domain even though it was detected on > the "wrong" bus! Because the code is written to assume that traffic > on bus #1 is legitimate, regardless of content (security vulnerability).Yes, I suppose a total idiot might design a secure system this way. Or they would design it to preserve security.>> And no, demanding separate displays and whatnot will never fly. > > Looking at a factory service manual for a Nissan Murano (we're in the > market for a new vehicle so I've been reading a lot of service manuals) > shows one or two CAN busses (depends on whether or not the vehicle has > the Advanced Driver Assistance System (ADAS) installed -- gizmo that acts > as a proxy for the driver). The *first* CAN bus always has the following > nodes: > - Engine Control Module > - Antilock Brake System > - Tranny Control Module > - Steering Angle Sensor > - All Wheel Drive Control Unit > - Automatic Backdoor Control Module > - Combination Meter (this is a display) > - Power Steering Control Module > - Audio / Visual Control Unit > - HVAC Control > - Body Control Module > - Intelligent Power Distribution Module > > When the ADAS is present, it resides on a separate CAN bus along with the > Driver Seat Control Unit and a Gateway Module (to the first bus). > > So, hack any of these modules -- regardless of how "critical" they > are for the vehicle to "operate as a means of transportation" -- and > you can effectively masquerade as *any* of the other nodes on the > same physical bus. And, potentially, as any node on the "other" > bus as well! I.e., if the A/V Unit is hacked and emits a message > that *should* have originated from the ADAS *via* the gateway, > how can any node on the first bus know that it was NOT propagated > to the bus by the gateway? How does any node know that it was > not generated *by* the ADAS???Why would the ADAS need to *control* any of the units on the secure bus? The ADAS might have commands to query devices on the secure bus, but if you allow control that is a way for hackers to get in. How does the A/V unit get hacked? Does it have a wireless connection? If so, that is a problem and needs to be corrected. -- Rick
Reply by ●July 23, 20152015-07-23
Am 23.07.2015 um 12:26 schrieb Don Y:> Exactly. Even if a "compromised" node does not have direct *physical* > access to a "special" bus, the fact that the compromised node can > effortlessly masquerade as ANY node on the bus(ses) to which it has > direct contact means any other gateway/bridge nodes *will* propagate > forged messages that it generates *to* that "other bus" AS IF the > messages were created by the genuine node instead.Only if the node it's masquerading as is on the same bus as the compromised one. And only if the firewall/gateway node is given no means to recognize the fact that there are now two data streams purporting to be from the same node.> This also assumes those gateway nodes are smart enough to recognize > *specific* traffic on "bus #1" as only legitimate *on* bus #1. I.e., > if a node on bus #1 forges a message that a node on bus #2 would > normally generate, the gateway *may* be naive enough to transport the > message across the protection domain even though it was detected on > the "wrong" bus!That error case is not a practically relevant one. Gateways have enough work on their plate as-is. They have to know which message they're supposed to receive on which bus, and which they're to echo/send, or they just couldn't handle the work load. Otherwise they would flood each network with the traffic of every other one.> Because the code is written to assume that traffic > on bus #1 is legitimate, regardless of content (security vulnerability).In practice, it's not. Car network designers really aren't _that_ daft (presently publicised bad example case possibly excluded).> Looking at a factory service manual for a Nissan Murano (we're in the > market for a new vehicle so I've been reading a lot of service manuals) > shows one or two CAN busses (depends on whether or not the vehicle has > the Advanced Driver Assistance System (ADAS) installed -- gizmo that acts > as a proxy for the driver). The *first* CAN bus always has the following > nodes: > - Engine Control Module > - Antilock Brake System > - Tranny Control Module > - Steering Angle Sensor > - All Wheel Drive Control Unit > - Automatic Backdoor Control Module > - Combination Meter (this is a display) > - Power Steering Control Module > - Audio / Visual Control Unit > - HVAC Control > - Body Control Module > - Intelligent Power Distribution ModuleThat's quite a small, old-fashioned layout by today's standards. A current-model passenger car would have between twice and four times as many CAN ECUs as that, and putting drive train control units on the same CAN network as, say A/V or HVAC ones has gone out of fashion about a decade ago. There are still some nodes that are so central that it would be hard to the point of impossible to isolate their security-sensitive functions from their other ones, e.g. the steering wheel group. These days buttons and levers on and around the steering wheel (for very good reason, too) control a wild mix of systems, only some of which are critical (cruise control, driver assistance, control over what gets displayed in the combination display, blinkers, wipers, radio, telephone, ...). And then there's the airbag sitting in the middle of all that. And the meaning of buttons will change based on what the multimedia central display currently shows, or what options were ordered with the car. Good luck trying to implement security isolation zones in _that_! And then new legal requirements like "E-Call" practically require to break any isolation barriers between established critical systems and others like the multimedia/navigation/telephone ones that are by _huge_ popular demand about as architecturally open and as connected as a desktop PC, and consequently about as security conscious as those. It's basically a miracle they largely managed to keep MS bloody Windows out of those boxes so far, and now they're supposed to perform survival-critical emergency tasks! That's insanity, and I'm quite sure everybody involved knows it.> I.e., if the A/V Unit is hacked and emits a message > that *should* have originated from the ADAS *via* the gateway, > how can any node on the first bus know that it was NOT propagated > to the bus by the gateway?For starters, the gateway itself knows that (because it should have been sending that message, not receiving it). And it doesn't take much engineering to make such extra message trains recognizable. About the simplest one is a rolling counter in the original messages. That doesn't allow yet to detect which of two message streams is actually genuine, but it does allow detection that something's foul in the state of Denmark.
Reply by ●July 23, 20152015-07-23
On 7/23/2015 3:38 PM, Hans-Bernhard Br�ker wrote:> > There are still some nodes that are so central that it would be hard to > the point of impossible to isolate their security-sensitive functions > from their other ones, e.g. the steering wheel group. These days > buttons and levers on and around the steering wheel (for very good > reason, too) control a wild mix of systems, only some of which are > critical (cruise control, driver assistance, control over what gets > displayed in the combination display, blinkers, wipers, radio, > telephone, ...). And then there's the airbag sitting in the middle of > all that. And the meaning of buttons will change based on what the > multimedia central display currently shows, or what options were ordered > with the car. Good luck trying to implement security isolation zones in > _that_!So why would there be only one bus to the steering column? My car has no CAN bus I'm pretty sure and has half those functions so that many wires. Reducing this to two buses should be duck soup. Using one UI for both secure and insecure functions is problematic and should not be done.> And then new legal requirements like "E-Call" practically require to > break any isolation barriers between established critical systems and > others like the multimedia/navigation/telephone ones that are by _huge_ > popular demand about as architecturally open and as connected as a > desktop PC, and consequently about as security conscious as those.Why would any of that have to connect to the secure systems? If it is needed to send a command to not allow the car to start or even to shut it down, that command would need a protocol that can not be duplicated, a secure protocol through a secure control point.> It's basically a miracle they largely managed to keep MS bloody Windows > out of those boxes so far, and now they're supposed to perform > survival-critical emergency tasks! That's insanity, and I'm quite sure > everybody involved knows it.Really? What critical emergency tasks are handled by the cell phone interface in a car? -- Rick
Reply by ●July 23, 20152015-07-23
Am 23.07.2015 um 22:36 schrieb rickman:> On 7/23/2015 3:38 PM, Hans-Bernhard Br�ker wrote:>> There are still some nodes that are so central that it would be hard to >> the point of impossible to isolate their security-sensitive functions >> from their other ones, e.g. the steering wheel group. These days >> buttons and levers on and around the steering wheel (for very good >> reason, too) control a wild mix of systems, only some of which are >> critical (cruise control, driver assistance, control over what gets >> displayed in the combination display, blinkers, wipers, radio, >> telephone, ...). And then there's the airbag sitting in the middle of >> all that. And the meaning of buttons will change based on what the >> multimedia central display currently shows, or what options were ordered >> with the car. Good luck trying to implement security isolation zones in >> _that_! > > So why would there be only one bus to the steering column?Because the electric pass-through mechanism from fixed to rotated assembly is brittle enough with just a few wires. Adding wires makes it worse.> Using one UI for both secure and insecure functions is problematic and > should not be done.That assumes the distinction is just two-fold. So: is the navigation system's next-turn indicator to be secure or not? Or the indication motor temperature gauge? Or the one for outside temperature? How much place would you need in the central behind-the-wheel combination display to be able to reserve a dedicated area (and isolated hardware to control it!) per security level? There's only that much space available... It's really not that simple. Automotive security involves not just data security. Some of it is safety-oriented UI design. E.g. all those user input devices are on and around the steering wheel for a reason: not because their function is safety-critical, but because it's safety-critical that the driver should keep his hands on the wheel, which _is_ safety-critical. And then there's that other unholy beast, called "the market", which flat-out _demands_ that of course it must be possible to navigate the entire 6000-entry MP3 collection while driving, and without taking the hands off the wheel. So now you "have to" put multi-purpose navigation buttons on the wheel, and a free-text display behind it that can show full ID3 tags, or people and magazines will laugh at your "prehistoric" infotainment system.>> And then new legal requirements like "E-Call" practically require to >> break any isolation barriers between established critical systems and >> others like the multimedia/navigation/telephone ones that are by _huge_ >> popular demand about as architecturally open and as connected as a >> desktop PC, and consequently about as security conscious as those. > > Why would any of that have to connect to the secure systems?Because it's the secure systems that diagnose a crash. eCall, in case you missed it, is an upcoming government requirement to implement an Automated Crash Response via cell-phone emergency calls, coupled with GPS and manual interaction. Basically, OnStar by law.
Reply by ●July 24, 20152015-07-24
On Wed, 22 Jul 2015 17:33:06 -0700, lasselangwadtchristensen wrote:> Den torsdag den 23. juli 2015 kl. 00.49.01 UTC+2 skrev rickman: >> On 7/22/2015 4:42 PM, Ian Yellowley wrote: >> > On Tuesday, 21 July 2015 14:22:18 UTC-8, Don Y wrote:>> I think it would be very easy to provide security between the safety >> functions and the rest of the automotive systems. Use separate buses. >> There are *very* few military systems that support multiple levels of >> security on the same hardware... for a good reason. They don't feel >> software can provide the level of security required unless it is very >> carefully implemented which is something they don't feel they can do >> for networking in general. I know of one system that was approved for >> multiple levels of security over a common network, but that took >> several years to develop and was a closed system. >> >> Why can't they just use a separate CAN bus for the safety related gear >> from the bus they use for the infotainment and climate controls, etc? >> The outside world could connect to the core automotive functions by >> wires or if wireless is needed they can use a separate wireless >> connection with high security or at least separate the two levels of >> security with a robust firewall. >> >> > From what I've heard from people that work with this stuff that is how > it is normally done, many separate busses access between them controlled > centrally and you would have physically open and reprogram hardware to > bypass that > > I don't know how Chrysler screwed it up >If I had to guess? Someone decided they could save something on the order of $5 per car by just running one network, and someone else approved it. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●July 24, 20152015-07-24
Rob Gaddi <rgaddi@technologyhighland.invalid> writes:> If I had to guess? Someone decided they could save something on the > order of $5 per car by just running one network, and someone else > approved it.An awful lot of these failures come from thinking (erroneously) that nobody would bother carrying out a given type of attack, rather than the attack itself being too subtle for the defender to conceive of.
Reply by ●July 24, 20152015-07-24
On 7/23/2015 5:56 PM, Hans-Bernhard Br�ker wrote:> Am 23.07.2015 um 22:36 schrieb rickman: >> On 7/23/2015 3:38 PM, Hans-Bernhard Br�ker wrote: > >>> There are still some nodes that are so central that it would be hard to >>> the point of impossible to isolate their security-sensitive functions >>> from their other ones, e.g. the steering wheel group. These days >>> buttons and levers on and around the steering wheel (for very good >>> reason, too) control a wild mix of systems, only some of which are >>> critical (cruise control, driver assistance, control over what gets >>> displayed in the combination display, blinkers, wipers, radio, >>> telephone, ...). And then there's the airbag sitting in the middle of >>> all that. And the meaning of buttons will change based on what the >>> multimedia central display currently shows, or what options were ordered >>> with the car. Good luck trying to implement security isolation zones in >>> _that_! >> >> So why would there be only one bus to the steering column? > > Because the electric pass-through mechanism from fixed to rotated > assembly is brittle enough with just a few wires. Adding wires makes it > worse.You snipped the part of my post that you should have read.>> Using one UI for both secure and insecure functions is problematic and >> should not be done. > > That assumes the distinction is just two-fold. So: is the navigation > system's next-turn indicator to be secure or not? Or the indication > motor temperature gauge? Or the one for outside temperature? > > How much place would you need in the central behind-the-wheel > combination display to be able to reserve a dedicated area (and isolated > hardware to control it!) per security level? There's only that much > space available... > > It's really not that simple. Automotive security involves not just data > security. Some of it is safety-oriented UI design. E.g. all those user > input devices are on and around the steering wheel for a reason: not > because their function is safety-critical, but because it's > safety-critical that the driver should keep his hands on the wheel, > which _is_ safety-critical. > > And then there's that other unholy beast, called "the market", which > flat-out _demands_ that of course it must be possible to navigate the > entire 6000-entry MP3 collection while driving, and without taking the > hands off the wheel. So now you "have to" put multi-purpose navigation > buttons on the wheel, and a free-text display behind it that can show > full ID3 tags, or people and magazines will laugh at your "prehistoric" > infotainment system.Nothing you have mentioned nullifies the need for isolation of the communications function of secure and insecure operations. I have worked on military radios which solve exactly the same type of problems. So clearly it is doable. Their requirements are for as near absolute security as possible so that it impacts price. But that can easily be mitigated by not focusing on attacks through the manufacturing channels (yes, the military worries about back doors built into commercial chips) and accepting commercial levels of security rather than state secret levels. That is, being as secure as credit card processing rather than NATO communications.>>> And then new legal requirements like "E-Call" practically require to >>> break any isolation barriers between established critical systems and >>> others like the multimedia/navigation/telephone ones that are by _huge_ >>> popular demand about as architecturally open and as connected as a >>> desktop PC, and consequently about as security conscious as those. >> >> Why would any of that have to connect to the secure systems? > > Because it's the secure systems that diagnose a crash. eCall, in case > you missed it, is an upcoming government requirement to implement an > Automated Crash Response via cell-phone emergency calls, coupled with > GPS and manual interaction. Basically, OnStar by law.None of that requires that the comms capability have any *controlling* access to the safety systems. Don't make easy problems hard. -- Rick
Reply by ●July 24, 20152015-07-24
On 7/24/2015 10:23 AM, Paul Rubin wrote:> Rob Gaddi <rgaddi@technologyhighland.invalid> writes: >> If I had to guess? Someone decided they could save something on the >> order of $5 per car by just running one network, and someone else >> approved it. > > An awful lot of these failures come from thinking (erroneously) that > nobody would bother carrying out a given type of attack, rather than the > attack itself being too subtle for the defender to conceive of.+42 "We don't need to reinforce the doors to the cockpit and provide DURABLE locks. think of all the fuel that would be consumed transporting those extra few pounds back and forth and back and forth across the country day in and day out! Who the hell would bother disturbing the flight crew?? That would be just plain SILLY! At the very least, the offender would be scolded and ordered back to their seat. And, probably face a HEAP of trouble when the aircraft *lands*! ... Huh? What's that? You mean the offender doesn't INTEND for it to land??? WTF??" In my case, why "protect" the network drops in my guest bedroom from accessing/hacking my automation system? Do I trust folks enough to invite them into my home -- but *distrust* them and want to protect myself from THEIR malicious hacks? This stupidly ignores the possibility that their *laptop* may initiate an attack based on malware already contained on it (or, attempt to connect to other machines in my home that don't normally "see the outside world") *or* malware that infects them during their visit! "They" (my houseguests) may have no role in the event -- other than plugging the laptop into the network connector!
Reply by ●July 24, 20152015-07-24
>> >> I don't know how Chrysler screwed it up >>Management: You guys need to get these new features working, STOP working on things that don't sell cars ! Engineers: If we don't fix these bugs, someone might be able to hack our hardware ! Management: Don't worry about hackers, they are not that smart.
