So this exploit is not specific to Tesla but rather any Linux 2.6.36 (and maybe up) that uses the 88W8688 (and maybe others), which could be a pretty common combination. And all that's required is an AP running the exploit, everything is automatic. Very impressive.
Definitely a common combination. The OLPC XO-1.5 was using this hardware 10+ years ago. It sounds like NX protections defeat the attack, and it looks like they went in soon after this kernel, around 2.6.38.
It appears that: Tesla bought this all-in-one ARM board from Parrot, and Parrot gave them a 2.6.36 kernel with thousands of custom patches in, and Tesla's not in much of a position to port it to a newer kernel, and then Parrot presumably went on to building other stuff and ignored keeping this kernel up to date and now we're here.
They (probably Parrot) might have updated it in the last year since the vulnerability was discovered though, it's hard to tell.
Does the Model S really run 2.6.36, first released ten years ago? I'm sure they're using a stable branch and keeping up with security patches in general [1], but that's still shocking to me.
[1]: although not 100% of security patches are going to end up in the stable@ queue or have their effect on 2.6.36 considered.
EDIT: See nils2014's comments below. The WiFi chip is connected to the entertainment system which received an updated kernel, but it is seems like the kernel on the WiFi chip itself may not have been updated.
Do they even still exist? It's impossible to find anything on these modules beyond FCC filings; some pixelated datasheets show the modules with "www.parrot.com" printed on them but going as far back as 2017 in the WWW archive, that site belongs to some drone startup.
Marvel fixed the bug in their firmware and apparently Tesla shipped some sort of update, I don't see anything that necessarily requires Parrot, the obscure maker of these modules, to do anything.
Oh! You misunderstood my question: I meant to ask whether Tesla's latest software update continues to ship a 2.6.36 kernel on Parrot, or a newer kernel instead, as they do for their other modules.
(Tesla uses the name Parrot to refer to this system in the car.)
A reason for them not to still be on 2.6.36 is that it's deeply exploitable.
I think the root of the confusion here is that you think Parrot is just a Tesla nickname. But Parrot is the name of the manufacturer of the fully-integrated WiFi+Bluetooth module so Tesla likely have nothing to do with the firmware that runs on that module with the ancient kernel.
Oh, I didn't get that impression. Keen's previous Black Hat paper made it sound like Tesla is dual-maintaining 2.6.36 and 4.x kernels, because they're unable/unwilling to upgrade from 2.6.36 on the Parrot board but are still issuing kernel fixes for it.
Looking at the datasheet some more, it does seem like the intention is for Tesla (or some other customer) to develop userland software and integrate that with Parrots SDK into a final firmware image for the module. But in that case, their situation is much the same as it is with the nVidia Tegra entertainment board: you are totally dependent on nVidia and Parrot to provide the basic infrastructure from bootloader to a Linux kernel with drivers to interface all the functionality they are selling you (a BSP). None of their hardware has any part upstreamed.
In Teslas position, as the ultimate vendor that is shipping this stuff on thousands of cars, you might decide that your supplier isn't forthcoming with security updates and decide to backport some isolated fixes to the kernel, but an upgrade from 2.6 to say even 4.4 is entirely out of the question; there are thousands of lines of hacked-together proprietary vendor code in those kernels where just going up a minor version will break the build. For a 2.6 based system in particular, you would essentially need to convert the entire board support to a device tree based system.
This is fine, but not an answer to the actual question of whether Tesla is still shipping 2.6.36 on a Model S's Parrot system today. Parrot-the-company could have given an updated kernel in the year or so since the vulnerability was reported, or like you say Tesla could have taken on the mammoth task of maintaining an out of tree arch port themselves. It would be useful to know whether this happened, since if it's still running 2.6.36 it would be reasonable to consider the devices as extremely vulnerable in the wild today.
> but an upgrade from 2.6 to say even 4.4 is entirely out of the question
We did this kind of transition at OLPC ten or so years ago, helping Marvell upstream enough of their arch support code for a new ARM SoC to move us from their private 2.6 branch to latest public upstream (including the move to device tree), and with only a few kernel engineers working on it. Tesla surely has many times more resources; it's not entirely out of the question, but it's true that it's probably not economical for a minor support chip. Although, it's the minor support chip that's connected to the outside world..
> there are thousands of lines of hacked-together proprietary vendor code in those kernels where just going up a minor version will break the build. For a 2.6 based system in particular, you would essentially need to convert the entire board support to a device tree based system.
What I don't get with these cases at all: by the GPL manufacturers are forced to provide the full (!) Linux kernel source code, same goes for u-boot. But while Tesla at least seems to provide source code (https://github.com/teslamotors), why the fuck and how can Android phone and other embedded device makers get away with not publishing anything?
Let's just take two examples of hardware that I know run Linux because I managed to root them:
- HP Z2100 24-inch plotter: firmware is at https://support.hp.com/sg-en/drivers/selfservice/hp-designje... (you have to select Windows XP 32-bit to see the firmware download, even though the firmware can be installed via anything capable of running a browser), and again, no mention of anything regarding Linux.
> why the fuck and how can Android phone and other embedded device makers get away with not publishing anything?
In general, the answer is that Linus Torvalds especially, and kernel developers in general, are very uninterested in filing copyright lawsuits, and it's them who have standing to bring a GPL violation lawsuit, rather than you as a purchaser -- it's not your rights that have been legally infringed, it's the code author's rights.
If the device manufacturer is not a US company (like the often-Chinese Android phone manufacturers), filing that lawsuit would be especially difficult even if the authors wanted to.
In these Sony and HP cases, they aren't required to put the source code on their firmware download pages. They're required to offer and produce it in response to a written request under GPLv2, or to instead bundle it with the hardware (e.g. on companion CD). You might find they actually do one of those two, since they're large US companies with mostly competent legal departments.
Incidentally, it took a lawsuit, or at least the imminent threat of one, for Tesla to start publishing kernel source: https://sfconservancy.org/blog/2018/may/18/tesla-incomplete-... . I think the lawsuit was primarily filed on behalf of Busybox authors rather than Linux authors.
It's important to remember that the GPL does not require that the modified source be publicly accessible, only available to those who you've distributed the modified program to. How that's verified and distributed is unspecified.
> only available to those who you've distributed the modified program to
That's not true. GPLv2 text:
> Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code
There's two issues with that. First, that's only one of three available options (two for commercial entities) that satisfy the license. The other is to include a copy of the source code with the software distribution. However, separately, this does not require that the source code be posted in a public place for anyone to access. You only must give with the distribution a written offer. That offer is valid to anyone, but it doesn't need to be posted in public and the source code does not need to be posted in public.
(Note that this article is only talking about the dashboard entertainment machine, which probably isn't the one the wifi chip's connected to. Perhaps that one got slower updates.)
You are right, but AFAIK they are running CentOS and Redhat have been back-porting security and fixes to major bugs at least until recently. CentOS 6 is in extended support phase 2 [1] Hopefully they move to CentOS 8 soon. I have no idea how this is implemented or if that parrot module has a flashable firmware. It is interesting that they say there is no support for NX. CentOS 6 which is based on the 2.6 kernel does support it. [2] That is not to say that things were compiled with the right options.
Agreed. Having all these systems with all the different distros / builds of linux sounds very difficult to maintain. I am not comfortable with cars that are remotely accessible as it is, especially if they have any self driving abilities. Elon also wants to make brain implants for people that will be remotely accessible.
I am probably thinking of the system that controls the driving, which I am 99% sure is CentOS 6. Reaching out to someone I know there.
There are many 10+ year old linux kernels in embedded devices all over the place, and much less secure systems and services on top of that. It's often called the internet of shitty things.
Right, but it's surprising that Tesla would be one of those vendors since they have an ongoing obligation to the security of their devices.
It looks like their open source disclosure of the kernel source is a 4.4 kernel, so something weird is going on there. Maybe they got off 2.6 since the time the vulnerability was discovered?
I see something saying they moved to 4.4 in the 8.1 update in June 2017, which is confusing because it suggests the vulnerability was never live.
But I also see they have multiple CPUs running Linux and don't update the kernel on all of them at the same time, so perhaps the CPU running the 8686 driver wasn't updated?
A former Tesla software engineer posted a thread on twitter a few months ago describing their development/release process and it was a total mess of hacky bad practices that barely worked at all.
It does not seem like software is much of a priority for them.
Most car manufacturers are reactive, like the Jeep hack a few years ago. Cyber Security should be on the forefront of their radar, but takes a back seat. So having outdated software is not that big of a surprise. I have a 3 year old phone that functions fine, but i might need to get a new one since it is full of security holes and no updates.
I find myself conflicted since i love the technology behind the new cars, but my paranoia about the lack of security and the inability of myself to do anything about it.
If only they had cameras in the cars so while they are applying the brakes when you are on the interstate they can collect that classic picture of horror on your face....
>If only they had cameras in the cars so while they are applying the brakes when you are on the interstate they can collect that classic picture of horror on your face....
They already do. IIRC Model 3 has about 6 external cameras and one internal one. However, the internal one is currently disabled and isn't used for anything, which is a subject to change for when they decide what to do with it and push it in an update.
If you are looking for some wtf road videos, we are bound to see more of them soon due to the most recent update Tesla pushed. It added the "save on honk" option, which (if enabled) saves some footage right before the honk, as well as about 5 seconds after the honk. With how much spicy footage the sentry mode update has provided in less than a year, I expect nothing less from the "save on honk" update.
As a sidenote, it isn't as bad as it seems in terms of privacy, because all videos (on-honk ones, or manual ones, or the sentry mode accidents) only get saved locally on your HDD/SSD/usb-drive/etc (whatever you have inserted into one of the front USB ports).
If you find WiFi-based attacks on devices to be interesting, you may be interested in the following research from Google Project Zero on attacking the iPhone’s WiFi stack (and linked are articles on Android):
Technically interesting and also interesting that this comes from Tencent.
> Tencent Holdings Limited is a Chinese multinational conglomerate holding company founded in 1998, whose subsidiaries specialise in various Internet-related services and products, entertainment, artificial intelligence and technology both in China and globally.
If you read the Apple product security announcements you'll find that they (as well as Qihoo 360) has been finding security vulnerabilities in unaffiliated companies' products for a long time. It's not unusual. They probably got the inspiration from Project Zero though.
Tencent has a number of security teams in addition to Keen Lab that have been around for a while: Xuanwu for example. I believe Keen Lab itself is some sort of acquisition of Keen Team, which did independent security research.
> All the two vulnerabilities we presented above are reported to Tesla in March 2019. Tesla already fixed them in version 2019.36.2, and the Marvell also has deployed a fix and published a security advisory[4] to the issue. The disclosure of the vulnerability research report had been communicated to Tesla, and Tesla is aware of our release.
I believe it’s less black and white than that - all of these organizations have both offensive and defensive priorities and sometimes choose to disclose exploits publicly after calculating their remaining value. See e.g.
By only connecting Tesla to AP with PMF (encrypted management frames) enabled, this exploit would not work? Because then you can not force a reconnect to AP using Deauthenticate frames.
I can agree on the Deauth, though it would maybe make it less receiptable to automated attack.
I see that Action frames also is encrypted and verified when enable PMF, so it is still viable to avoid the exploit?
Was I the only one to notice the scrolling phallus doing things on the the status line for "waiting for Telsa to join our AP" on the article's attached video?
The MCU is pretty well decoupled from any driving controls other than helping to display a bit of info like the speedometer. I mean it can even be rebooted anytime while driving. So I suspect the larger effect would be on things like entertainment features. Not really driving. But yes harhar, nice play on words.
Well.. that and GPS and all the worries about logging long term GPS location data, user info and mics and so on. Not a crash risk but could totally be exploited for nasty means. Plus you could falsify data too.
