885
edits
Changes
Jump to navigation
Jump to search
Line 62:
Line 62: + + + + + + + + + + + + + + Line 123:
Line 137: − + Line 168:
Line 182: − + Line 192:
Line 206: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 257:
Line 307: + + + + + + + + + + + Line 423:
Line 484: − + Line 434:
Line 495: − + + + + + + + + + + + + + +
also checked at reset
| April 9, 2018
| April 9, 2018
| [[User:SciresM|SciresM]], almost surely others (independently).
| [[User:SciresM|SciresM]], almost surely others (independently).
|-
| Poor validation of bootrom SDRAM configuration parameters leads to arbitrary writes in bootrom
|
The Tegra X1 bootrom supports saving SDRAM parameters to scratch registers, and using the saved configuration to enable DRAM during warmboot.
The code that parses these parameters does if (params->EmcBctSpareN) *params->EmcBctSpareN = params->EmcBctSpareNPlusOne for most N, without validating either the address or value written to it.
There are other arbitrary writes in this code, as well (e.g. BootromPatch parameters intended for patching MISC registers do not check a relative offset to 0x7000000, etc).
This allows a user with access to the PMC registers (via pre-sleep bpmp execution, or otherwise) to gain arbitrary bootrom code execution.
| None
| HAC-001 (Tegra210)
| 2017
| December 16, 2018
| Everyone (independently).
|}
|}
| January 2018
| January 2018
| April 29, 2018
| April 29, 2018
| [[User:Hexkyz|hexkyz]]
| [[User:Hexkyz|hexkyz]], probably others (independently).
|-
|-
| pk1ldrhax
| pk1ldrhax
| December 2017 (Probably earlier by others)
| December 2017 (Probably earlier by others)
| January 18, 2018
| January 18, 2018
| [[User:SciresM|SciresM]], probably others.
| [[User:SciresM|SciresM]], probably others (independently).
|-
|-
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| January, 2018
| January, 2018
| February 23, 2018
| February 23, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others, independently.
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others (independently).
|-
|-
| TSEC has access to the secure kernel carveout
| TrustZone is responsible for managing security carveouts to prevent DMA controllers from accessing the carveout which contains the kernel, sysmodules, and other critical operating system data.
Until [[8.0.0]], the list of devices that could access the carveout included the TSEC. However, the TSEC can bypass the SMMU when in authenticated mode by writing to a certain register. Thus, pwning nvservices would allow one to take over the TSEC, and use it to write to normally protected mmio/memory.
In [[8.0.0]], this was fixed by removing TSEC access, and adding TSECB access (TSECB cannot bypass the SMMU).
| With access to the TSEC mmio (nvservices ROP) and code execution in TSEC Heavy Secure mode, kernel code execution, probably.
| [[8.0.0]]
| [[8.0.0]]
| 2017 (when TrustZone code plaintext was first obtained).
| April 15, 2019
| Everyone
|-
| deja vu (insufficient system state validation on suspend leads to pre-sleep BPMP code execution)
| Jamais Vu was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry, since gaining pre-sleep code execution on the BPMP compromises the system.
However, the state validation performed by Nintendo's Secure Monitor was insufficient to prevent pre-sleep execution from being obtained.
Prior to [[6.0.0]], one could use a DMA controller that had access to IRAM and was not held in reset (there were multiple) to race TrustZone's writes to the BPMP firmware in IRAM, and thus overwrite Nintendo's firmware with an attacker's to gain pre-sleep code execution.
[[6.0.0]] addressed this by performing TrustZone state MAC writes and locking PMC scratch *before* turning on the BPMP, fixing the original Jamais Vu exploit entirely. In addition, the BPMP firmware in TrustZone's .rodata is now memcmp'd to the actual data after it is written to IRAM. This mitigates race attacks that modify the firmware.
However, Nintendo both forgot to validate the BPMP exception vectors after writing them, and forgot to hold in reset a DMA controller that can write to the BPMP's exception vectors.
AHB-DMA is not blacklisted by kernel mapping whitelist (Nintendo probably forgot it, because the TX1 TRM does not really document that it's present, although the MMIO works as documented in older (Tegra 3 and before) TRMs).
Thus, with kernel code execution (or some other way of accessing AHB-DMA, e.g. nspwn on <= 4.1.0, TSEC hax, or other arbitrary mmio access flaws), one can DMA to the BPMP's exception vectors as they are written, causing TrustZone to start the BPMP executing an attacker's firmware at a different location than TrustZone intends/validates.
This was fixed in [[8.0.0]] by blocking AHB-DMA arbitration and verifying it is held in reset during suspend, and thus there are no more devices that can write to the relevant MMIO at the right time.
| Arbitrary TrustZone/BootROM code execution, by using either the original Jamais Vu flaw (prior to [[6.0.0]] or a warmboot bootrom exploit (any firmware where pre-sleep execution can be gained).
| [[8.0.0]]
| [[8.0.0]]
| December 2017
| April 15, 2019
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]] and ktemkin, [[User:Naehrwert|naehrwert]] (independently), almost certainly others (independently)
|}
|}
| January 2018
| January 2018
| [[User:SciresM|SciresM]], [[User:Yellows8|yellows8]]
| [[User:SciresM|SciresM]], [[User:Yellows8|yellows8]]
|-
| Potential [[SVC|svcWaitForAddress]] thread use-after-free
| Between [[4.0.0]], where svcWaitForAddress was introduced, and [[7.0.0]], there was a second intrusive rbtree node in KThread for the WaitForAddress tree (the key being (address, priority), sorted lexicographically). Unlike the WaitProcessWideKeyAtomic tree, the kernel forgot to reinsert the WaitForAddress node when the thread's priority changed (priority inheritance and/or SetPriority), breaking the rbtree invariants; and since the kernel walks through the entire tree to remove intrusive nodes, you could cause threads to stay in the tree even after their deletion.
[[7.0.0]] fixed the issue by using the same intrusive node for both trees. The thread/node knows which tree it is in, and the latter is correctly updated when thread priority changes.
| It unluckily didn't look exploitable
| [[7.0.0]]
| [[7.0.0]]
| July 2018
| February 2019
| [[User:TuxSH|TuxSH]]
|-
|-
|}
|}
|
|
| November 2, 2018
| November 2, 2018
| [[User:hexkyz|hexkyz]], probably others.
| [[User:hexkyz|hexkyz]], probably others (independently).
|-
|-
| nvhax (memory corruption in nvservices system module)
| nvhax (memory corruption in nvservices system module)
| [[6.2.0]]
| [[6.2.0]]
| [[6.2.0]]
| [[6.2.0]]
| June 2017
| April 5, 2017
| November 24, 2018
| November 24, 2018
| [[User:hexkyz|hexkyz]]
| [[User:hexkyz|hexkyz]]
|-
| Infoleak in nvservices system module
| The [[NV_services|nvservices]] ioctl [[NV_services#NVMAP_IOC_ALLOC|NVMAP_IOC_ALLOC]] takes an optional argument "addr" which allows the calling process to pass a pointer to user allocated memory for backing a nvmap object. If "addr" is left as 0, nvservices uses the transfer memory region (donated by the user during initialization) instead, when allocating memory for the nvmap object.
By design, freeing the nvmap object by calling the ioctl [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] returns, in its "refcount" argument, the user address previously supplied if the reference count reaches 0.
However, prior to [[6.2.0]], the case where the transfer memory region is used to allocate the nvmap object was not taken into account, thus resulting in [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] leaking back an address from within the transfer memory region mapped in nvservices' memory space.
In [[6.2.0]], [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] no longer returns the address when the transfer memory region is used instead of user supplied memory.
| Combined with other vulnerabilities: Defeating ASLR in nvservices sysmodule.
| [[6.2.0]]
| [[6.2.0]]
| April 2017
| November 24, 2018
| Everyone
|-
|-
|}
|}