CVE‑2019‑5680 for TK1 L4T?

According to threatpost’s article “Researcher creates ‘Selfblow’ proof-of-concept attack for exploiting a vulnerability that exists in “every single Tegra device released so far”.”

Does this mean the TK1 LT4 is also vulnerable and if so, will a new L4T release come from this?

In the EOL for NVIDIA Jetson TK1 Developer Kit it was stated:

Does this deem a new release necessary? A software update for the TX1 has been issued, but will the TK1 follow?

The demo only shows flashing with malware. Then it is suggested that someone would gain root privilege through a javascript web browser attack. What I’m curious is whether there is an actual javascript web browser attack on ARMv7-a or ARMv8-a? This part was not clear, it wasn’t mentioned whether that is hypothetical or actual.

So far as allowing someone to reinstall part of the operating system by being physically there that’s pretty hard to stop. If this applied to a PC one could put a BIOS modification password in place, but this wouldn’t prevent GRUB itself from being modified. If a PC install password protected the BIOS it is a simple task to remove the CMOS battery, momentarily short the reset pins, and then boot…that removes the password. So then the chassis might have an intrusion detection switch, but those are a bit of a joke. So far as I can tell everything making the exploit of value requires being physically there with a second PC to flash. This would change dramatically if the remote javascript exploit is real, but then the remote javascript exploit itself to gain root access would be the bug needing mitigation. The javascript exploit is the one which is the more interesting topic since gaining root access in the first place adds so many more ways of adding exploits, but it is the part of the problem which wasn’t demonstrated.

My comments are not to say it isn’t worth understanding this exploit, it’s just a fascinating topic and I’m not yet sure such an exploit has any real risk without physical access (but someone deploying a system for remote edge computing without a secure container might have a real risk). I myself would pretty much give up on security being “strong” in cases where the attacker has the ability to physically access and reinstall part of the boot environment via flash…I don’t know of any PC or other installation which is safe after a third party install disk was allowed to run. The other part of interest was where it mentioned being able to read memory after an improper shutdown:

"That is when sensitive data becomes available to attackers via a computer’s RAM because the machine wasn’t
shut down properly."

There are a number of articles out on the internet about something similar in PCs, whereby a system which has been shut down usually leaves the RAM with the data which was in the RAM at the moment of shutdown; then by physically accessing the PC and using the right hardware one can look directly at the memory and read its content from before the shutdown. If you can imagine the amount of trouble it would take to read the DIMM content of a PC while it is shut down (but on standby) then it becomes obvious this would be a very advanced attack even with physical access. To prevent that it would be necessary to either cut power entirely, without any kind of standby mode so that RAM loses state, or to reboot to something like memtest86+ to randomly alter all of the RAM (if you were to add content to randomize RAM at shutdown, then you would simply wait for an improper shutdown which skips randomizing RAM).

Personally, if I knew of a javascript exploit which could gain root access, then there are probably much better ways to exploit the system than to wait for physical access of an improperly shut down system and read the RAM. Obviously every vulnerability is important, but I’m not personally too worried about someone secretly flashing something to my system and then reading from the RAM. On the other hand, javascript exploits could be serious even without the exploit the article mentions.