RE: CAN Bus Standard Vulnerability

Hi Freddy,

You are so right!  Protocol is everything.

The authors didn't even mention the flaw in the CAN protocol that requires toggle messages to not be used since the target node may well miss the message and be error passive so it can't flag the message with a dominant error flag while others provide the ACK because they do receive the message.

And that's without any one doing something evil to the bus.

John Dammeyer


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Lars-Berno Fredriksson
> Sent: August-19-17 12:57 PM
> To: [email protected]; [email protected]
> Subject: Re: [CANLIST] CAN Bus Standard Vulnerability
> 
> Hi John,
> 
> This just� shows how sloppy the automotive industry is. When I designed
> can systems, the system node generated an alert state if there were more
> that one error frame in 10.000 messages. If there were more than one in
> 1000 messages, it went into a "safe critical" mode. The CAN feature of
> error counters is only for non-safety and non-time critical systems.
> 
> The first step in time- (and safety-) critical system design is to
> schedule every message that can be scheduled. Then you have a good start
> for a dependable system. A bonus is that you have made it at least an
> order of magnitude difficult to hack.
> 
> It is a shame that any car system could be hacked as showed! It shows
> that the system designer should have had another job, e.g., as a teacher
> in roman history.
> 
> Cheers,
> Freddy
> 
> On 2017-08-19 18:08, John Dammeyer wrote:
> > Seriously?
> > Those groups are making noise like this is a critical issue that must be
> addressed.
> >
> > Everyone who works with CAN bus knows that physical access to the bus
> means the network can be compromised.  Duh!
> >
> > That's true for every type of communications protocol where you can either
> inject messages or intercept and rebroadcast.  And once doesn't need the OBD-
> II connector to do this.  For that matter the OBD-II CAN connection often
> doesn't even touch the real CAN buses used on a vehicle.  Assume a vehicle uses
> the Freescale 9S12 with 5 CAN bus channels.  One channel specifically to
> generate the OBD-II port, one for the instrument panel, one for engine to
> transmission, one to body electronics and I still have one left over.
> >
> > So if you want to damage messages you have to hack into physical wiring for a
> specific bus and not just a connector.  Any car company dumb enough to put a
> system critical bus on the OBD-II connector will find themselves with a recall
> I'm sure.
> >
> > Next to do this is relatively easy. Years ago I worked with a semiconductor
> company to develop what I called the CBMM or CAN Bus Message Marker.  It's
> express purpose (using an FPGA) was to park on the CAN bus and look for
> specific CAN IDs and then create an Error Flag of 6 dominant bits.  It also had an
> occurrence counter so we could do this more than one time so we could create
> bus warning, bus passive right up to bus off events.  The tool was use to verify
> that individual custom modules would properly hand a bus off situation.  We
> could target both transmitters of messages and the receivers.  This was at a
> time when CAN devices didn't provide access to the Rx and Tx error count
> registers.
> >
> > Next tool was almost a decade later.   The CAN CRC is designed to work best
> with an 11 bit ID message size and still does with the 29 bit ID.  It's not an
> effective CRC for the longer messages that show up with CAN FD.  I've been out
> of that world long enough now that I don't know if they use a different CRC
> when sending FD size messages.  Back in 2000 when we used a custom CAN like
> protocol virtually identical to what CAN FD is now, IIRC we changed the CRC for
> the 2K sized messages that held Ethernet packets.  (We were sending MPG4
> over power line)
> >
> > For that project I had to break the CAN bus in a different way by exploiting the
> CRC vulnerability.  CAN handles single bit errors.  It can even handle multiple bit
> errors that are contiguous as in the type caused by noise.  The CRC cannot
> handle random errors across the entire message designed to corrupt only the
> data portion leaving the ID and CRC intact.  Done correctly the appropriate bits
> are changed so the CRC is correct but the data bytes have been changed.
> >
> > But even that can't be done deterministically because you can only actively
> inject dominant bits on top of recessive bits and there's no way to know that if
> you change this bit this time that it will cause an error not detected by the
> higher level protocol.
> >
> > Finally to really do damage one needs access to the firmware of a module to
> modify the code or even replace it internally with different hardware so it
> becomes a bridge and then the sky is the limit.  I don't know of too many
> MilCAN type products (tanks etc) that would allow someone to replace a
> module.  Someone in a dealer service department could do this with your car.
> But they'd have to be really motivated to create a new module.
> >
> > So let's not panic.  CAN bus requires physical access in a way that is far
> beyond the WiFi and Iot world.
> >
> > My 2 cents.
> > John Dammeyer
> >
> >
> >
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]] On
> >> Behalf Of SorasakListReader
> >> Sent: August-19-17 4:37 AM
> >> To: [email protected]
> >> Subject: [CANLIST] CAN Bus Standard Vulnerability
> >>
> >> Interesting:
> >>
> >> Alert (ICS-ALERT-17-209-01)
> >> CAN Bus Standard Vulnerability
> >> https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-209-01
> >>
> >>
> >> Unpatchable Flaw Affects Most of Today's Modern Cars
> >> https://www.bleepingcomputer.com/news/security/unpatchable-flaw-
> affects-
> >> most-of-todays-modern-cars/
> >>
> >>
> >> The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard
> >> http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-
> >> hack/
> >>
> >>
> >> --
> >> Archives and useful links: http://groups.yahoo.com/group/CANbus
> >> Subscribe and unsubscribe at www.vector.com/canlist/
> >> Report any problems to <[email protected]>
> > --
> > Archives and useful links: http://groups.yahoo.com/group/CANbus
> > Subscribe and unsubscribe at www.vector.com/canlist/
> > Report any problems to <[email protected]>


--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>