SatoshiLabs
On Tuesday December 18th, we released the firmware update 1.7.2 for Trezor One devices. This is a release which brings support for sending OMNI assets. OMNI is a platform built on top of Bitcoin used by various cryptocurrencies such as Tether. It also fixes a security issue located in the U2F subsystem that we have discovered internally on November 26th.
Please note that several other vendors are also affected by this issue, which influenced aspects of our disclosure process. We would like to thank these vendors for their immediate response and willingness to release their updates so quickly.
The vulnerability consists of an information disclosure in the initial handshake of the U2F protocol which could potentially be leveraged to extract sensitive data. It was found during research by Christian Reitter (independent security researcher working closely with SatoshiLabs) in coordination with Dr. Jochen Hoenicke (security researcher at SatoshiLabs) and was immediately disclosed.
After assessing the impact on the Trezor One, Christian identified a number of external open-source projects which also used the affected data structure and began a coordinated responsible disclosure to inform them confidentially over encrypted and authenticated channels. During this process, we have worked with several projects to help them determine the practical impact on their project. All projects have agreed to the proposed coordinated disclosure.
There is no evidence that the vulnerability has been used in practice. However, we encourage everyone to keep their Trezor devices up-to-date at all times.
Details about the U2FHID_INIT_RESP information leak vulnerability BackgroundThe open Universal 2nd Factor ( U2F ) standard is a strong second factor security mechanism that helps user to keep their important accounts safe. Two factor authentication systems help in the unfortunate event that account credentials are e.g. stolen by malware. In this scenario, despite obtaining username and password, an attacker will be unable to derive the cryptographic key held within the U2F device and is blocked from authenticating successfully without it to sites that have this protection enabled.
The Trezor One enumerates as a standard U2F HID USB device to fulfill its role as a fully featured U2F hardware token. This functionality was developed on the basis of the C/C++ reference implementation for U2F by Yubico , one of the companies that created this security standard. This reference implementation defines essential data structures & protocol characteristics and is therefore used in parts for several other U2F implementations such as the Trezor One, and the affected data structure originates there.
At the beginning of each U2F session, host computer and U2F client device perform a basic two-way handshake before any cryptographic request such as a site authentication is issued. This handshake contains the information leak that is described in the following paragraph.
IssueThe C struct `U2FHID_INIT_RESP` represents the U2F message payload of the U2FHID_INIT handshake reply sent by the Trezor. It is intended to store 17 bytes as defined by the FIDO U2F HID specification . However, due to automatic optimizations related to memory layouts and address boundaries, this particular struct is transparently padded to a new size of 20 bytes by default during compilation. The resulting three additional bytes of hidden data are inaccessible through the regular struct fields, but the `sizeof()` value is increased. This configuration is referred to as an unpacked struct and compilers generally do this to speed up accesses. However, only a minority of structs will be padded, making this behavior easier to miss in practice.
In the `u2fhid_init()` function, `U2FHID_INIT_RESP` is used directly to assemble the message contents of the reply message, and during this process, every regular data field is overwritten with valid data. However, since the struct memory area was not cleared with zeros during initialization and the three hidden data bytes are never written to, these three bytes still contain the raw data that was present in this memory area during the struct initialization, which represents discarded memory of previous Trezor operations .
U2FHID_INIT_RESP resp; // several write operations to the regular resp data fields // [...] memcpy(&f.init.data, &resp, sizeof(resp));At the end of `u2fhid_init()`, the memcpy copies all 20 bytes including the problematic trailing bytes into the packet transmit buffer, from where they are transmitted over USB with each U2FHID_INIT packet.
ImpactThe information leak consists of three memory bytes. The returned value have been observed to be stable between subsequent U2F handshake packets and device reboots, but can vary depending on previous actions on the Trezor. This behavior suggests that particular memory contents such as the existing stack protection defense mechanism are likely not impacted. Additionally, Trezor functions that handle sensitive data are designed to scrub the memory areas of the relevant variables before discarding them, which reduces the probability that the information leak can directly expose sensitive data. This can be seen as a mitigating factor, but we are taking no risks and have moved forward to release a patched firmware as soon as possible. This is also motivated by the fact that the problematic function can be invoked without any form of authentication and is not protected by the PIN, because of the U2F design.
Please also note that due to memory layout differences, the exact leak behavior will differ between firmware versions and vendors.
How does this affect the TrezorOne?The described vulnerability can be used by an attacker with local access to the U2F interface to read a small area of previously discarded memory of the Trezor One. During research, we have so far been unable to escalate this to any meaningful compromise or exposure of sensitive data.
How was the issuefixed?The bug was fixed by correcting the memory layout of the affected struct via the __attribute__((packed)) and overwriting it with zeros upon initialization.
Timeline 2018 11 26: U2FHID_INIT_RESP information leak is discovered 2018 11 30: Advance notice to vendor #2 2018 12 05: Disclosure to vendor #2 2018 12 12: Disclosure to vendor #3 2018 12 15: Disclosure to vendor #4 (no practical impact) 2018 12 18: Coordinated public disclosure Frequently Asked Questions Is my Trezor Onesafe?The described vulnerability can be used to read a small area of discarded memory. During research, we have so far been unable to escalate this to any meaningful compromise or exposure of sensitive data. In addition, there is no evidence that this vulnerability has been used in practice . However, we encourage everyone to keep their Trezor devices up-to-date at all times.
Is Trezor Model T affected?
