Check that the CVEs are executed when we use our application stack

[rtadros125]

We have listed the CVEs that exist in the FreeRTOS version we elected to use, and we claim that these CVEs exit in our application stack. The list is in this document, and we updated the CVEs/CWEs spreasheet accordingly.

This ticket is about the following: We should verify that each of these CVEs is actually activated/can-be-activated in our application stack. And update the list and the spreadsheet accordingly. We would like to have them all, so if one of them does not exist; can we include it somehow? This ticket is about doing this investigation.

[rod-chapman]

I don't understand the title of this Issue. What are "The CVEs"?

[rtadros125]

My apologies for that. I have updated the ticket's description. Please lmk if you have questions.

[rod-chapman]

So do you mean that I should just study the code to see if the specific vulnerability still exists in there, or should I try to actually write an exploit program?

[rod-chapman]

Well.. the two CVE we listed against WolfSSL certainly aren't there, because they relate to ECDSA signatures and elliptic curves that we're not using...

[rod-chapman]

What does "our TCP/IP stack" mean? it seems to imply there some other "not our TCP/IP stack"? That doesn't make sense... you mean the one-and-only FreeRTOS-Plus-TCP code, right?

[rtadros125]

So do you mean that I should just study the code to see if the specific vulnerability still exists in there, or should I try to actually write an exploit program?

No need for an exploit program. You can either know by inspection, or run smth small for testing to know whether this part is being executed or not.

Well.. the two CVE we listed against WolfSSL certainly aren't there, because they relate to ECDSA signatures and elliptic curves that we're not using...

Aha. This is exactly what we need to do in this ticket.

What does "our TCP/IP stack" mean? it seems to imply there some other "not our TCP/IP stack"? That doesn't make sense... you mean the one-and-only FreeRTOS-Plus-TCP code, right?

When I first wrote this, we were still using TCP for some of the tasks. What I meant is our application stack; i.e. the program that will be running during the competition, whether the codes we wrote or the kernel/io codes that will be running. Sorry for the confusion.

[rod-chapman]

OK... I plan to study each CVE to see if it is (still) applicable to the combination of application code, libraries and the FreeRTOS build that we're using. I will post a new Comment here with results of that analysis for each CVS listed in the vulnerabilitiesCoverage.md file

[rod-chapman]

CVE-2019-18178: Real Time Engineers FreeRTOS+FAT 160919a has a use after free. The function FF_Close() is defined in ff_file.c. The file handler pxFile is freed by ffconfigFREE, which (by default) is a macro definition of vPortFree(), but it is reused to flush modified file content from the cache to disk by the function FF_FlushCache().

Further info and analysis

This bug was fixed in November 2019 here

Impact on FETT

We are not using FreeRTOS-Plus-FAT, and the source file ff_file.c does not exist in our build, so this CVE cannot be exploited in FETT.

[rod-chapman]

CVE-2019-13120: Amazon FreeRTOS up to and including v1.4.8 lacks length checking in prvProcessReceivedPublish, resulting in untargetable leakage of arbitrary memory contents on a device to an attacker. If an attacker has the authorization to send a malformed MQTT publish packet to an Amazon IoT Thing, which interacts with an associated vulnerable MQTT message in the application, specific circumstances could trigger this vulnerability.

Further info and analysis

This bug was fixed in Amazon FreeRTOS v1.4.9 in June 2019 here

Impact on FETT

We are not using FreeRTOS MQTT library, and the source file mqtt/mqtt_lib.c does not exist in our build, so this CVE cannot be exploited in FETT.

[rod-chapman]

CVE-2018-16603: An issue was discovered in Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component. Out of bounds access to TCP source and destination port fields in xProcessReceivedTCPPacket can leak data back to an attacker.

Further info and analysis

More details of the discovery from October 2018 are here

The problem were reportedly fixed in Amazon FreeRTOS v1.3.2 in August 2018

The issue is a lack of checking the length of a received data buffer before accessing data fields of that buffer in the function xProcessReceivedTCPPacket() in FreeRTOS_TCP_IP.c

The correction was committed here

Impact on FETT

This vulnerability is potentially exploitable in FETT, assuming that attackers can craft malicious TCP packets and send them to the target. The vulnerability offers "information leakage" but it is not certain how this might be seen to fulfull a "win" criterion for FETT.

[rod-chapman]

CVE-2018-16602: An issue was discovered in Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component. Out of bounds memory access during parsing of DHCP responses in prvProcessDHCPReplies can be used for information disclosure.

Further info and analysis

More details of the discovery from October 2018 are here

The problem were reportedly fixed in Amazon FreeRTOS v1.3.2 in August 2018

The correction was committed here

Impact on FETT

Currently, FETT is compiled with the macro configUSE_DHCP set to 0 in FreeRTOSIPConfig.h, so the offending code is not compiled. Analysis of the ELF file disassembly confirms that the prvProcessDHCPReplies() function is not present in our build.

As such, this vulnerability is not exploitable in FETT at the moment. We could "accidentally" re-enable it by setting configUSE_DHCP to 1 if we choose.

Update

DHCP has been re-enabled (PR#397) so this vulnerability is potentially exploitable.

[rod-chapman]

CVE-2018-16601: An issue was discovered in Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component. A crafted IP header triggers a full memory space copy in prvProcessIPPacket, leading to denial of service and possibly remote code execution.

Further info and analysis

More details of the discovery from October 2018 are here. That report details the attack scenario:

If an attacker supplies an IP header length field (uxHeaderLength) that’s larger than the whole packet (pxNetworkBuffer->xDataLength) minus ipSIZE_OF_IPv4_HEADER (20), the computation of xMoveLen will cause an integer underflow. This will cause memmove to move a huge chunk of data, covering the entire 32 bit memory area, with a very little range to play with.

The problem were reportedly fixed in Amazon FreeRTOS v1.3.2 in August 2018

The correction was committed [here](https://github.com/aws/amazon-freertos/commit/12ea022d0f52df211111a79e0aca1ca7b04639d6#diff-50c0dd671d7134eb364a26b6cd8a9cf0

Impact on FETT

This vulnerability is potentially exploitable in FETT, assuming that attackers can craft malicious IP packets and send them to the target. The vulnerability is critical in that it offers the attacker the potential to "memmove" any area of memory.

[rod-chapman]

CVE-2018-16600: An issue was discovered in Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component. Out of bounds memory access during parsing of ARP packets in eARPProcessPacket can be used for information disclosure.

Further info and analysis

More details of the discovery from October 2018 are here. That report details the attack scenario:

Fields of the ARP packet are accessed without doing proper boundary checking, which means out of bounds data can be accessed. An attacker can leak information by observing the responses for truncated ARP packets.

The correction was made and committed (in FreeRTOS_IP.c before the call to eARPProcessPacket()) here

Impact on FETT

This vulnerability is potentially exploitable in FETT, assuming that attackers can craft malicious ethernet packets and send them to the target. Analysis of our sources and the disassembly of the ELF file confirms that this code is present in our build.

[rod-chapman]

CVE-2018-16599: An issue was discovered in Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component. Out of bounds memory access during parsing of NBNS packets in prvTreatNBNS can be used for information disclosure.

Further info and analysis

More details of the discovery from October 2018 are here.

NBNS is the "NetBios Name Service". Code for this exists within the FreeRTOS_DNS.c module.

Impact on FETT

Currently, our FreeRTOSIPConfig.h excludes NBNS (the define configUSE_NBNS is set to 0) from our build. Analysis of the disassembled ELF file confirms that the offending code is not included in our build, so this vulnerability is not exploitable in FETT at the moment.

[rod-chapman]

CVE-2018-16598: An issue was discovered in Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component. In xProcessReceivedUDPPacket and prvParseDNSReply, any received DNS response is accepted, without confirming it matches a sent DNS request.

Further info and analysis

More details of the discovery from October 2018 are here.

This analysis notes that an attacker "can poison the DNS cache of the device."

Impact on FETT

Currently, our build does not include DNS support. Our FreeRTOSIPConfig.h (somewhat confusingly) defines:

#ifndef FETT_APPS
#define ipconfigUSE_DNS 1
#endif

But FETT_APPS is defined, so DNS is excluded.

Therefore, this vulnerability is not exploitable in FETT.

Update

DNS has been re-enabled (PR#397) so this is potentially exploitable.

[rod-chapman]

CVE-2018-16528: Amazon Web Services (AWS) FreeRTOS through 1.3.1 allows remote attackers to execute arbitrary code because of mbedTLS context object corruption in prvSetupConnection and GGD_SecureConnect_Connect in AWS TLS connectivity modules.

Further info and analysis

More details of the discovery from October 2018 are here. It notes:

The MQTT agent and GGD modules misuse the API of mbedTLS, creating a corrupt mbedTLS context object. The corrupt object may lead to remote code execution.

Impact on FETT

We use neither mbedTLS nor MQTT so this is not exploitable in FETT.

[rod-chapman]

CVE-2018-16527: Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component allow information disclosure during parsing of ICMP packets in prvProcessICMPPacket.

Further info and analysis

More details of the discovery from October 2018 are here. It notes:

prvProcessICMPPacket doesn’t validate that the received frame is large enough to be an ICMP packet, and can access fields from this packet out of bounds. The attacker can leak information by observing the response to a truncated ICMP echo request.

Impact on FETT

Potentially exploitable. Our FreeRTOS build is configured to support replying to incoming PING requests, which is a part of the ICMP protocol.

It is not clear what sort of "information leak" would consititute a "win" for the purposes of the FETT bog bounty exercise.

[rod-chapman]

CVE-2018-16526: Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component allow remote attackers to leak information or execute arbitrary code because of a Buffer Overflow during generation of a protocol checksum in usGenerateProtocolChecksum and prvProcessIPPacket.

Further info and analysis

More details of the discovery from October 2018 are here. It gives a detailed explanation of the exploit, concluding:

An attacker can leak information. (Only with BufferAllocation_2.c) An attacker can achieve remote code execution on the device.

These problems were fixed in FreeRTOS_IP.c here

Impact on FETT

This vulnerability is exploitable in FETT. Our build does use BufferAllocation_2.c, so remote code execution may also be possible.

[rod-chapman]

CVE-2018-16525: Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component allow remote attackers to execute arbitrary code or leak information because of a Buffer Overflow during parsing of DNS\LLMNR packets in prvParseDNSReply.

Further info and analysis

More details of the discovery from October 2018 are here. It notes two distinct bugs:

1. The first is that the length of a UDP packet header is not checked in prvProcessIPPacket().

2. The second concenrs parsing errors in DNS requests.

Impact on FETT

The first vulnerability is exploitable in FETT. Its potential impact in unknown.

The second (DNS) vulnerability cannot be exploited in FETT, since we build FETT with DNS disabled. Analysis of the disassembled ELF file confirms that the offending code is absent from our build.

Update

DNS re-enabled by PR#397, so exploitable.

[rod-chapman]

CVE-2018-16524: Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component allow information disclosure during parsing of TCP options in prvCheckOptions.

Further info and analysis

More details of the discovery from October 2018 are here.

Lack of data-length checks in prvCheckOptions() can lead to information leakage.

The corrected code (in FreeRTOS_TCP_IP.c) was committed here

Impact on FETT

Explotable assuming the attacker can craft malicious IP packets.

[rod-chapman]

CVE-2018-16523: Amazon Web Services (AWS) FreeRTOS through 1.3.1, FreeRTOS up to V10.0.1 (with FreeRTOS+TCP), and WITTENSTEIN WHIS Connect middleware TCP/IP component allow division by zero in prvCheckOptions.

Further info and analysis

More details of the discovery from October 2018 are here.

Again, the offending code is in prvCheckOptions() in FreeRTOS_TCP_IP.c

The code that deals with the MSS TCP Option contains a potential for division-by-zero if an attacker supplies a requested MSS of zero.

The corrected code (in FreeRTOS_TCP_IP.c) was committed here

Impact on FETT

On most targets, this would constitute a denial-of-service attack, since division-by-zero typically leads to a processor exception and/or termination of the application.

For FETT, though, we note that the RISC-V ISA does not trap on division-by-zero, but carries on with the result -1 (signed) or 2^32-1 (unsigned). More analysis is required how this turn of events would affect the FETT application.

[rod-chapman]

CVE-2018-16522: Amazon Web Services (AWS) FreeRTOS through 1.3.1 has an uninitialized pointer free in SOCKETS_SetSockOpt.

Further info and analysis

More details of the discovery from October 2018 are here.

Impact on FETT

This vulnerability exists in the "AWS Secure Sockets" library here which is not used in FETT.

Therefore, this vulnerability is not exploitable in FETT.

[rod-chapman]

Summary:

For the 15 CVS listed for FreeRTOS-10.0.1:

5 - not exploitable owing to the entire module being absent or not used. 2 - not exploitable currently (but could be if we change FreeRTOSIPConfig.h to include the offending code) 5 - Exploitable (potential information leak) 2 - Exploitable (undefined behaviour) 1 - Exploitable (potential remote code injection/execution)

[rod-chapman]

For WolfSSL, BOTH CVEs are not exploitable because the offending module (ECDSA) is not used in FETT.

[rod-chapman]

To do:

1. Discuss if we can "re-enable" 2 potential vulnerabilities by including more buggy code in our build...
2. Update the vulnerabilities document and spreadsheet accordingly.

[rtadros125]

Thank you so much. This is exactly what we needed. I'd say we'll have to remove the 7 non-exploitable from the document and the spreadsheet. @kiniry I know you won't like this, but please advise.

[kiniry]

Thanks Rod. That's a great write-up and analysis. Let's investigate "re-enabling" the 2 potential vulnerabilities to include more buggy code in the build.

[rod-chapman]

I will re-enable these locally and try a test run with them on my F1. I will check the generated code and final binary to make sure that the potentially buggy code really is there (a decent linker would detect that it's un-called, and chuck it away, of course...)

[rod-chapman]

CVE-2018-16602 can be re-enabled by changing 2 #defines in FreeRTOSIPConfig.h This adds 11kbytes to the ELF file. I have done this and tested on F1 and seems OK.

[rod-chapman]

CVE-2018-16525 re-enabled by setting ipconfigUSE_DNS in fettFreeRTOSConfig.h See "enable_cves" branch in both this repo, and also in the FreeRTOS-10.0.1 repo.

[rod-chapman]

Opened PR#397 here and PR#28 in the FreeRTOS-10.0.1 repo

[rod-chapman]

Opened SSITH-FETT-Docs PR#41 to cover document updates

[rod-chapman]

Closing following PR#397