Faiblesses connexes
| CWE-ID |
Nom de la faiblesse |
Source |
| CWE-787 |
Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer. |
|
Métriques
| Métriques |
Score |
Gravité |
CVSS Vecteur |
Source |
| V3.0 |
9.8 |
CRITICAL |
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Base: Exploitabilty MetricsThe Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component. Attack Vector This metric reflects the context by which vulnerability exploitation is possible. A vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable one or more network hops away (e.g. across layer 3 boundaries from routers). Attack Complexity This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component. Privileges Required This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack. User Interaction This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. The vulnerable system can be exploited without interaction from any user. Base: Scope MetricsAn important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges. Scope Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports. An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same. Base: Impact MetricsThe Impact metrics refer to the properties of the impacted component. Confidentiality Impact This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server. Integrity Impact This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component. Availability Impact This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable). Temporal MetricsThe Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability. Environmental Metrics
|
[email protected] |
| V2 |
10 |
|
AV:N/AC:L/Au:N/C:C/I:C/A:C |
[email protected] |
EPSS
EPSS est un modèle de notation qui prédit la probabilité qu'une vulnérabilité soit exploitée.
Score EPSS
Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 et 100 %). Plus la note est élevée, plus la probabilité qu'une vulnérabilité soit exploitée est grande.
Percentile EPSS
Le percentile est utilisé pour classer les CVE en fonction de leur score EPSS. Par exemple, une CVE dans le 95e percentile selon son score EPSS est plus susceptible d'être exploitée que 95 % des autres CVE. Ainsi, le percentile sert à comparer le score EPSS d'une CVE par rapport à d'autres CVE.
Informations sur l'Exploit
Exploit Database EDB-ID : 41806
Date de publication : 2017-04-03 22h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1047
Broadcom produces Wi-Fi HardMAC SoCs which are used to handle the PHY and MAC layer processing. These chips are present in both mobile devices and Wi-Fi routers, and are capable of handling many Wi-Fi related events without delegating to the host OS.
One of the events handled by the BCM firmware is the processing of TDLS connections (802.11z). TDLS connections allow clients to exchange data between one another without passing it through the AP (thus preventing congestion at the AP).
In order to verify the integrity of TDLS messages, each message exchanged between the TDLS peers includes a message integrity code (MIC). The MIC is calculated using AES-CMAC with a key derived during the setup process (TPK-KCK).
When a TDLS Setup Request frame is sent by either one of the peers in an established TDLS connection, the receiving client must verify the MIC before processing the request. The MIC for TDLS Setup Request and TDLS Setup Confirm frames is calculated as follows:
AES-CMAC(TPK-KCK, InitiatorMAC ||
ResponderMAC ||
TransactionSeq ||
LinkID-IE ||
RSN-IE ||
TimeoutInterval-IE ||
FastTransition-IE)
(see "wpa_tdls_ftie_mic" under https://w1.fi/cgit/hostap/plain/src/rsn_supp/tdls.c)
All TDLS connections are accepted automatically from any peer and are handled solely by the BCM firmware (meaning there is no need for user interaction or involvement in any way - once a TDLS Setup Request is received by the firmware, it will proceed with the TDLS handshake and subsequently create a TDLS connection with the requesting peer).
When the BCM firmware receives a TDLS Setup request frame, it verifies the MIC and responds with a TDLS Setup Response frame. The initiator then sends a TDLS Setup confirm frame in order to establish the connection. The BCM firmware uses the "wlc_tdls_cal_mic_chk" function to calculate the MIC of the received frames (both for the setup and the confirm). When processing the TDLS Setup Request frame, the RSN IE is verified and parsed in order to proceed with the derivation of the TPK. This verification also makes sure that the length of the RSN IE is valid for the chosen encryption type. However, when a TDLS Setup Confirm (M3) message is received, the firmware fails to verify the RSN IE, before calling the "wlc_tdls_cal_mic_chk" function in order to verify the MIC of the incoming frame.
The "wlc_tdls_cal_mic_chk" function allocates a buffer of size 256 on the heap, into which the needed information elements are gathered in order to calculate the AES-CMAC. However, the function does not sufficiently verify the length of the RSN IE included in the Setup Confirm frame. This allows an attacker to include an abnormally large RSN IE, causing a heap-overflow in "wlc_tdls_cal_mic_chk".
Here is the approximate simplified high-level code for the function:
1. uint8_t* buffer = malloc(256);
2. uint8_t* pos = buffer;
3.
4. //Copying the initial (static) information
5. uint8_t* linkid_ie = bcm_parse_tlvs(..., 101);
6. memcpy(pos, linkid_ie + 0x8, 0x6); pos += 0x6; //Initiator MAC
7. memcpy(pos, linkid_ie + 0xE, 0x6); pos += 0x6; //Responder MAC
8. *pos = transaction_seq; pos++; //TransactionSeq
9. memcpy(pos, linkid_ie, 0x14); pos += 0x14; //LinkID-IE
10.
11. //Copying the RSN IE
12. uint8_t* rsn_ie = bcm_parse_tlvs(..., 48);
13. if (rsn_ie[1] + 2 + (pos - buffer) > 0xFF) {
14. ... //Handle overflow
15. }
16. memcpy(pos, rsn_ie, rsn_ie[1] + 2); pos += rsn_ie[1] + 2; //RSN-IE
17.
18. //Copying the remaining IEs
19. uint8_t* timeout_ie = bcm_parse_tlvs(..., 56);
20. uint8_t* ft_ie = bcm_parse_tlvs(..., 55);
21. memcpy(pos, timeout_ie, 0x7); pos += 0x7; //Timeout Interval IE
22. memcpy(pos, ft_ie, 0x54); pos += 0x54; //Fast-Transition IE
As can be seen above, although the function verifies that the RSN IE's length does not exceed the allocated buffer (line 13), it fails to verify that the subsequent IEs also do not overflow the buffer. As such, setting the RSN IE's length to a large value (i.e., such that rsn_ie[1] + 2 + (pos - buffer) == 0xFF) will cause the Timeout Interval and Fast Transition IEs to be copied out-of-bounds, overflowing the buffer.
It should be noted that prior to calculating the MIC, the function in charge of processing the TDLS Setup Confirm frame calls a helper function in order to verify the nonce values in the FTIE (to make sure they match the nonces in the TDLS Setup Request and TDLS Setup Response frames, M1 & M2). However, since the attacker is the initiator of the TDLS connection, they may choose the value of Snonce (bytes [52-84) of the FTIE) arbitrarily. This leaves only the Anonce (bytes [20-52) of the FTIE) as uncontrolled bytes during the overflow, since they are chosen by the responder.
It should also be noted that the heap implementation used in the BCM firmware does not perform safe unlinking or include heap header cookies, allowing heap overflows such as the one described above to be exploited more reliably.
I'm attaching a patch to wpa_supplicant 2.6 which modifies the TDLS Setup Confirm frame sent by the supplicant in order to trigger the heap overflow. You can reproduce the issue by following these steps:
1. Download wpa_supplicant 2.6 from https://w1.fi/releases/wpa_supplicant-2.6.tar.gz
2. Apply the included patch file
3. Build wpa_supplicant (with TDLS support)
4. Use wpa_supplicant to connect to a network
5. Connect to wpa_cli:
5.1. Setup a TDLS connection to the BCM peer using "TDLS_SETUP <MAC_ADDRESS_OF_PEER>"
(Where MAC_ADDRESS_OF_PEER is the MAC address of a peer with a BCM SoC which is associated to the same network).
At this point the heap overflow will be triggered. The code in the patch will corrupt the heap, causing the remote BCM SoC to reset after a while.
I've been able to verify this vulnerability on the BCM4339 chip, running version 6.37.34.40 (as present on the Nexus 5). However, I believe this vulnerability's scope includes a wider range of Broadcom SoCs and versions.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41806.zip
Exploit Database EDB-ID : 41805
Date de publication : 2017-04-03 22h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes
Source:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1046
https://googleprojectzero.blogspot.ca/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
Broadcom produces Wi-Fi HardMAC SoCs which are used to handle the PHY and MAC layer processing. These chips are present in both mobile devices and Wi-Fi routers, and are capable of handling many Wi-Fi related events without delegating to the host OS.
One of the events handled by the BCM firmware is the processing of TDLS connections (802.11z). TDLS connections allow clients to exchange data between one another without passing it through the AP (thus preventing congestion at the AP).
In order to verify the integrity of TDLS messages, each message exchanged between the TDLS peers includes a message integrity code (MIC). The MIC is calculated using AES-CMAC with a key derived during the setup process (TPK-KCK).
When a TDLS Teardown Request frame is sent by either one of the peers in an established TDLS connection, the receiving client must verify the MIC before processing the request. The MIC for TDLS teardown requests is calculated as follows:
AES-CMAC(TPK-KCK, LinkID-IE || ReasonCode || DialogToken || TransactionSeq || FastTransition-IE)
(see "wpa_tdls_key_mic_teardown" under https://w1.fi/cgit/hostap/plain/src/rsn_supp/tdls.c)
It should be noted that all TDLS connections are accepted automatically from any peer and are handled solely by the BCM firmware (meaning there is no need for user interaction or involvement in any way - once a TDLS Setup Request is received by the firmware, it will proceed with the TDLS handshake and subsequently create a TDLS connection with the requesting peer).
When the BCM firmware receives a TDLS Teardown frame, it first verifies the Link-ID information element in order to make sure it matches the current link information. Then, if the Link ID is valid, it calls the "wlc_tdls_cal_teardown_mic_chk" function in order to verify the MIC of the request. The function starts by extracting the Fast Transition IE information element (FTIE - number 55). Then, if the IE is present, its contents are copied into a heap-allocated buffer of length 256. The copy is performed using the length field present in the IE, and at a fixed offset from the buffer's start address. Since the length of the FTIE is not verified prior to the copy, this allows an attacker to include a large FTIE (e.g., with a length field of 255), causing the memcpy to overflow the heap-allocated buffer.
Here's the high-level logic of the "wlc_tdls_cal_teardown_mic_chk" function:
uint8_t* buffer = malloc(256);
...
uint8_t* linkid_ie = bcm_parse_tlvs(..., 101);
memcpy(buffer, linkid_ie, 0x14);
...
uint8_t* ft_ie = bcm_parse_tlvs(..., 55);
memcpy(buf + 0x18, ft_ie, ft_ie[1] + 2);
(Note that each IE is a TLV; the tag and value fields are each a single byte long. Therefore, ft_ie[1] is the IE's length field).
It should also be noted that the heap implementation used in the BCM firmware does not perform safe unlinking or include heap header cookies, allowing heap overflows such as the one described above to be exploited more reliably.
I'm attaching a patch to wpa_supplicant 2.6 which modifies the TDLS Teardown frame sent by the supplicant in order to trigger the heap overflow. You can reproduce the issue by following these steps:
1. Download wpa_supplicant 2.6 from https://w1.fi/releases/wpa_supplicant-2.6.tar.gz
2. Apply the included patch file
3. Build wpa_supplicant (with TDLS support)
4. Use wpa_supplicant to connect to a network
5. Connect to wpa_cli:
5.1. Setup a TDLS connection to the BCM peer using "TDLS_SETUP <MAC_ADDRESS_OF_PEER>"
5.2. Teardown the connection using "TDLS_TEARDOWN <MAC_ADDRESS_OF_PEER>"
(Where MAC_ADDRESS_OF_PEER is the MAC address of a peer with a BCM SoC which is associated to the same network).
At this point the heap overflow will be triggered. The code in the patch will corrupt the heap, causing the remote BCM SoC to reset after a while.
I've been able to verify this vulnerability on the BCM4339 chip, running version 6.37.34.40 (as present on the Nexus 5). However, I believe this vulnerability's scope includes a wider range of Broadcom SoCs and versions.
patch
################################################################################
Attaching exploit - running exploit.py results in arbitrary code-execution on the Wi-Fi dongle.
Here is a high-level overview of the exploit:
1. Create a TDLS connection to the target device
2. Teardown the connection using a crafted "TDLS Teardown Request" frame, triggering the overflow
3. Create a new TDLS connection, using crafted arguments causing a situation where two chunks in
the freelist overlap one another
4. Send a TDLS frame with action code 127
4.1. Craft the size of the TDLS frame s.t. it overlaps the other chunk in the freelist
4.2. Craft the contents in order to point the free chunk to the location of a periodic timer
which was created during the firmware's initialization
5. Send another TDLS frame with action code 127
5.1. Craft the size of the TDLS frame s.t. it will be placed on top of the timer object
5.2. Craft the contents in order to replace the timer's data structures, allowing us to point
the timer's handler function at any arbitrary address. In this case, we point the handler
function at an address near the heap's end
6. Send a large TDLS frame with action code 127
6.1. Craft the frame's contents so that it contains the shellcode we'd like to execute
7. Since the heap is zero-initialized, and "00 00" is NOP (MOVS R0,R0) in Thumb, this means that
jumping to a location slightly before our created code chunk is fine, as it won't cause any
adverse affects until we reach our code blob. Putting all this together, Once the timer
expires, our code chunk is executed on the firmware
Note that sending crafted "TDLS Teardown Request" frames requires modifications to wpa_supplicant.
Moreover, sending TDLS frames with action code 127 requires modifications to both wpa_supplicant
and to the Linux Kernel (mac80211).
These changes (and instructions on how to apply them) are included in the exploit archive attached
to this comment.
TDLSExploit-1.tar.gz
################################################################################
Attaching updated exploits for both the Nexus 5 (MRA58K, BCM4339 6.37.34.40) and the Nexus 6P (NUF26K, BCM4358 version 7.112.201.1).
TDLSExploit-2.tar.gz
################################################################################
Adding firmware heap visualisers.
-create_dot_graph.py - Creates a "dot" graph containing the heap's free-chunks
-create_html_main_chunk.py - Creates an HTML visualisation of the heap's main region
-create_html_total.py - Created an HTML visualisation of the entire heap
-create_trace_html.py - Creates an HTML visualisation for traces from the malloc/free patches
-profiles.py - The symbols for each firmware "profile"
-utils.py - Utilities related to handling a firmware snapshot
BCMHeapVisualisers.tar.gz
################################################################################
Adding script to dump the timer list from a firmware snapshot.
dump_timers.py
################################################################################
Adding script to dump PCI ring information from firmware snapshot.
dump_pci.py
################################################################################
Adding inline firmware patcher.
-patch.py - The patcher itself.
-apply_* - Scripts to apply each of the patches using dhdutil
-<DEV>/BCMFreePatch - Patch for the "free" function in the firmware
-<DEV>/BCMMallocPatch - Patch for the "malloc" function in the firmware
-<DEV>/BCMDumpMPU - Patch that dumps the MPU's contents
BCMPatcher.tar.gz
Proofs of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41805.zip
Products Mentioned
Configuraton 0
Linux>>Linux_kernel >> Version 3.10
Linux>>Linux_kernel >> Version 3.18
Références
