Tesla Motors Linux Kernel

41 pointsposted 9 months ago
by wslh
(github.com)

9 Comments

walterbell

9 months ago

Such Open. Much Wow.

  Tesla OpenSource committed on May 17 
  Showing 161 changed files with 13,686 additions and 1,939 deletions
  Showing 5,586 changed files with 69,988 additions and 53,751 deletions

anonbanker

9 months ago

Oooh, kernel 5.4 This means that Teslas are vulnerable to every exploit discovered since, and anyone wanting to gain full access to the system has a multitude of tools to get there.

i4k

9 months ago

No, this does not mean that. An old version can be fully patched (at least all upstream newer bugs fixed). Not saying it's the case here though...

hi-v-rocknroll

9 months ago

Not necessarily. The problem with clipboard audits using version number matching alone is they don't account for patching. The proper way to do a vulnerability audit is by building and running code under test in sandboxed environment, and running each CVE-indicative sploit against it. For example, RHEL would be a Swiss cheese exploit magnet if they didn't regularly patch the heck out of every CVE for every component that came down the feed.

fargle

9 months ago

> The proper way to do a vulnerability audit is by building and running code under test in sandboxed environment, and running each CVE-indicative sploit against it.

that doesn't work if there isn't an exploit

the other problem with both "clipboard audits" and your suggestion is that neither take into account the full context of the system. in general, a potential vulnerability might be significant, but in the context of your system, or tesla's, it might often be completely irrelevant. the converse is also true, and more problematic. it is very common for a potential vulnerability to be masked by other system characteristics.

the only way to do an audit is to do a comprehensive review of known potential vulnerabilities in the full context of your entire system stack and a well defined threat model requirement. otherwise, you will both underestimate some and overestimate many others. and you can't assume this is static; it must be repeated continuously because inputs and assumptions are constantly changing.

patch-and-pray is worse than a waste of time.

hi-v-rocknroll

9 months ago

The gold standard deep and certain vulnerability remediation requires A/B test exploit sample code.

You're really going off into the weeds about other concerns rather than covering and ensuring known flaws don't exist than can be checked automatically and mechanically given proper infrastructure that don't need significant or constant human attention. There is a place for human attention, but it isn't going to scale to check 10 million machines.