etc.[VisualPro Tech Brief] A Car Navigation Unit Was Rooted. What Is the Risk in TARA Terms?
01Summary
02Rooting a head unit to fix a clock
On November 2, Estonian researcher Rasmus Moorats published a blog post on how he got root on the factory navigation unit (TomTom Carminat LIVE) of his 2014 Renault Latitude. When daylight saving time ended, the clock was an hour off, and the time setting only appeared with a genuine map SD card inserted. A replacement card would have cost about 60 euros, so he decided to work around it.
The unit runs on Linux 2.6.28.10, but it was not unprotected. Update images carried a signature, the root file system was read-only, and most other partitions were mounted noexec. The SD card was protected by DRM tied to the card ID. The way in was a boot-time feature that reads a script (master.script) from the SD card. When the driver presses "Yes" on the "Execute master.script?" prompt, a parser running as root processes the script.
There were two weaknesses. The script's LOG command did not check file paths, so it could write outside its log folder. The SHEX command could launch a program but could not pass arguments. Using LOG, the researcher overwrote the kernel setting core_pattern so that a crashing program would run a script from the SD card. Using SHEX, he launched dbus-monitor, which crashed, and the kernel ran his script as root. He then backed up the internal storage and fixed the clock by editing the time zone offset in a settings file.
The original post states that physical access and the driver's approval are required. It does not cover the vehicle network (CAN) or other ECUs, and it mentions neither a disclosure to the manufacturer nor a CVE. The vehicle architecture and scores in the example below are educational assumptions based on this research.
03Splitting "we got root" along two axes
A TARA under ISO/SAE 21434 rates each threat on two separate axes. One is attack feasibility, how easy the attack is. The other is impact, the damage to safety, finances, operations and privacy if it succeeds. The risk value comes from both together. Root access is only an intermediate step in an attack, so it has no rating of its own.
For the example, we created one fictional head unit in VisualPro TARA and assumed two vehicle architectures. In architecture A, the head unit only receives data from the vehicle network. In architecture B, it can send messages to the vehicle control domain through a gateway. The attacker is someone who rents or shares the car. That person can stay in the car for a long time and presses the prompt themselves.
| Damage scenario | Impact | Architecture |
|---|---|---|
| DS-1 Previous users' contacts and location history leaked | Privacy, Major | A, B |
| DS-2 Head unit function lost through tampered navigation data or settings | Operational, Moderate | A, B |
| DS-3 Vehicle function malfunctions while driving due to forged control messages | Safety, Severe | B only |
04An attack path built from two weaknesses
The researcher's method fails if any one step is missing. In VisualPro, such a path is drawn with an AND gate. Threat TH-1 (copying contacts and location history) has two paths. AP-1 finds the chain by analyzing the firmware, as the researcher did. AP-2 follows the published write-up step by step.
Both paths share one step: "insert the SD card in the car and approve the prompt." The prompt is a useful defense against someone slipping an SD card into another person's car. It does nothing when the attacker is the person in the driver's seat, such as a rental customer, the buyer of a used car, or a workshop employee holding the keys.
05Disclosure changes feasibility
VisualPro's attack potential method adds up scores for five factors: elapsed time, specialist expertise, knowledge of the item, window of opportunity and equipment. The lower the total, the easier the attack: 0 to 13 is High, 14 to 19 is Medium, 20 to 24 is Low, and 25 or more is Very Low.
| Factor | AP-1 before disclosure | AP-2 after disclosure |
|---|---|---|
| Elapsed time | 17 (up to 6 months: firmware analysis, emulator build) | 0 (within a day) |
| Specialist expertise | 6 (expert) | 3 (proficient: can read the post and adapt a script) |
| Knowledge of the item | 3 (restricted: firmware obtained and analyzed) | 0 (public) |
| Window of opportunity | 1 (easy: own or rented car) | 1 (easy) |
| Equipment | 0 (ordinary PC and SD card) | 0 (ordinary PC and SD card) |
| Total and rating | 27, Very Low | 4, High |
The difference comes from knowledge, not from equipment or access. Once a route the researcher found through firmware analysis and an emulator is published as one post, the next person can follow it within a day. A threat's feasibility usually follows its easiest path, and VisualPro aggregates it that way, rating TH-1 as High overall. Had the first TARA contained only AP-1, TH-1 would have had risk value 1. Adding AP-2 after publication raised it to 4.
06The highest risk was not vehicle control
The result runs slightly against intuition. The highest risk value belongs to TH-1, the leak of previous users' personal data, because the attack needs nothing beyond the published steps and its feasibility is High. TH-3 in architecture B has a Severe impact, yet its risk value is 3. Reaching root on the head unit follows the published steps, but learning which message formats the gateway lets through takes confidential information, specialized equipment and an expert's time. That brings its total to 22 (Low).
This does not mean TH-3 can wait. The first step of its path is already open to anyone, and only the gateway remains. If the gateway's message rules leak or are published by other research, its feasibility will jump the same way TH-1's did. In architecture A, TH-3 does not exist at all. With the same head unit, the vehicle architecture sets the ceiling on damage.
07Attach cybersecurity goals to the shared step
We set three goals. SG-1, "do not execute scripts from removable media whose origin is not verified," blocks the step that appears in all four paths. The original unit required signatures on update images, but the boot-time script was processed as root after nothing more than the driver's confirmation. SG-2 covers personal data in vehicles whose users change, and SG-3 covers the gateway boundary in architecture B. The goals overlap so that SG-2 and SG-3 still limit the damage if SG-1 fails.
Cars built in 2014 are still on the road. Head units rarely receive patches, so research published after launch is the most common event that changes attack feasibility.
08Five checks for your own product
- Privileges for removable media and diagnostic input: List which process handles files from SD cards, USB and diagnostic ports, and with what privileges. If they run as root, check for signature verification on that path.
- When a prompt counts as a control: Before counting user approval as a security control, ask whether the person approving could be the attacker. Rental, shared and used cars, and cars in for service, are typical cases.
- Add a path when research is published: Rather than editing existing scores, add a separate post-disclosure path. Re-rating knowledge, expertise and elapsed time updates the threat's feasibility automatically.
- Boundaries that assume the head unit is compromised: Start by checking whether the head unit can send messages to the vehicle control domain at all. If it can, check whether the gateway allow list is the last line of defense.
- Personal data in cars whose users change: Check whether contacts and location history are erased or encrypted when users change. In this example, that is where the highest risk value appeared.
09Frequently asked questions
Q1Should TARA cover attacks that require physical access?
Yes. The need for physical access is reflected in the window of opportunity score. For people who use a car for long periods, though, physical access is easy. Assess cases where the attacker sits inside the car, such as rental customers or workshops, as well.
Q2How do we update a TARA when a researcher publishes a vulnerability?
Add a new attack path that follows the published steps, and re-rate knowledge of the item, expertise and elapsed time. A threat's feasibility follows its easiest path, so the risk value can change. In this example, the same threat moved from risk value 1 to 4.
Q3Should we simply treat threats in order of risk value?
Risk values set priorities. Even so, for threats with a large safety impact, check separately how many lines of defense remain, even when the risk value is lower. In this example, TH-3 has risk value 3, but after the published steps only the gateway stands in the way.
The vehicle architecture, impact ratings and attack potential scores in the example are educational assumptions, not an assessment of any specific vehicle or product.
References
· Rasmus Moorats, "Jailbreaking my car's navigation system just so I can change the time" (2026-11-02) — Read the post
· Cyber Security News, "Renault Car's 15-Year-Old Linux Navigation Software Hacked to Execute Arbitrary Root Commands" (2026-11-03) — Read the article
· ISO/SAE 21434 Road vehicles — Cybersecurity engineering — ISO page