Through the Window: Exploitation and Countermeasures of the ESP32 Register Window Overflow^†

Round 1

Reviewer 1 Report

The submitted manuscript deals with the exploitability of Xtensa’s register window overflow. The following aspects need to be addressed in a revised version of the paper in order to improve its quality.

1. The introduction should be more supported by appropriate references.

2. The contributions of the paper should be clearly highlighted at the end of the introduction.

3. The conclusions are too shallow.

Author Response

Dear Reviewer,

Thank you very much for your review. We hope you will be pleased with our revision. Please find below our responses to your comments.

The introduction should be more supported by appropriate references.

We have included additional references for Stack Canaries and Return-Oriented Programming.

The contributions of the paper should be clearly highlighted at the end of the introduction.

We have modified this part in the introduction. It now clearly names the contributions of the original paper as well as the extended paper. It now reads as follows:

“This work is an extension to a paper first presented at the International Telecommunication Networks and Applications Conference 2022 (ITNAC 2022) [7]. The contributions of the original paper were the introduction of a new vulnerability that utilizes the window overflow exception handlers of the Xtensa LX architecture. Countermeasures were introduced to mitigate the vulnerability. One particular countermeasure that involves a small patch of the exception handlers was evaluated. With this extension we hope to provide a better introduction into the field as well as a more detailed discussion of the vulnerability. We also extended our evaluation by moving to a real board instead of relying on simulations, leading to unexpected results as well as an adaption to our benchmark methodology using a synthetic benchmark as an addition to the CoreMark benchmark. We also extended our discussion of the feasibility of the vulnerability in regards of memory safety measures of the ESP32 microcontroller.”

The conclusions are too shallow.

We have rewritten the conclusion section which now includes distinct conclusions of the original paper as well as conclusions of the extension. It now reads as follows:

“This paper extended the contents of [7]. This previous paper introduced a new vulnerability that allows the attacker to use an unprotected stack pointer to manipulate arbitrary memory addresses. The paper demonstrated how this vulnerability can be used to disable Stack Canaries and even discussed possibilities to combine it with other attack techniques such as ROP. It introduced a low-cost software patch for this vulnerability and used simulations in combination with the CoreMark benchmark to evaluate its overhead. The simulated Xtensa core only had 32 general purpose registers and the overhead ranged between 0.104% and 0.423%. It also showed the overhead for the exception handlers only which increased by 36.60%. These results were also included in this paper.

This paper extended the content by using a ESP32-WROVER-E development board for evaluation instead of simulations. This board uses two Xtensa LX6 cores, each with 64 general purpose registers. We believe this difference led to the significant differences in our measured results. The overhead of the patch measured for the microcontroller was between 0.0021% and 0.0065%. Additionally, a new benchmark was developed to showcase the worst-case scenario. It was designed to maximize the occurrence of window overflows, but can also scale and represent larger programs. In the worst case we showed that we were able to get up to 9.68% overhead, which is still far below the 36.60% measured in the simulation. Limits of the attack as well as defense mechanisms were discussed in detail.

In conclusion, the presented vulnerability can be a threat to systems that may have a buffer overflow vulnerability and insufficient protection. Our software patch should be easy to apply to existing systems with negligible consequences to the systems performance. It is also easy to integrate in an existing code base to protect systems. In the future, the vulnerability will hopefully be resolved by replacing vulnerable devices either with devices that are patched, or by devices using the next generation of Xtensa cores that do not contain the vulnerability anymore.”

Reviewer 2 Report

This article proposes a low-cost and easy-to-implement protection for vulnerabilities targeting the Xtensa LX architecture that attackers can use to leak or overwrite sensitive data. They used simulations for the proof of concept.

The authors should address the minor issues I have noted in their submitted article (Please refer to my comments on the document.)

Comments for author File: Comments.pdf

You need to revise the building of the sentences, the links between the sentences, and the flow of the information.

Author Response

Dear Reviewer,

Thank you very much for your review. We hope you will be pleased with our revision. Please find below our responses to your comments.

You need to revise the building of the sentences, the links between the sentences, and the flow of the information.

We did a careful revision of the paper trying to improve the language, and we hope that now it reads better.

Comments in the attached document:

If you could revise the title to put in perspective your evaluation.

We have adapted the title of the paper to better fit the content of the extended paper. The new title is: “Through the Window: Exploitation and Countermeasures of the ESP32 Register Window Overflow”

For the abstract: You need to provide specifics on the presented mitigation technique, and the results of the evaluation.

Thank you for this remark. We have re-written the abstract and more specific information to it. The abstract now reads as follows:

“With the increasing popularity of IoT (Internet-of-Things) devices their security becomes a more and more important issue. Buffer overflow vulnerabilities are known for decades but are still relevant, especially for embedded devices where certain security measures cannot be implemented due to hardware restrictions or simply due to their impact on performance. Therefore, many buffer overflow detection mechanisms check for overflows only before critical data is used. All data that an attacker could use for his own purposes can be considered critical. It is therefore essential that all critical data is checked between writing a buffer and its usage. This paper presents a vulnerability of the ESP32 microcontroller, which is used in millions of IoT devices, that is based on a pointer that is not protected by classic buffer overflow detection mechanisms like Stack Canaries, or Shadow Stacks. This paper discusses the implications of the vulnerability and presents mitigation techniques, including a patch, that fixes the vulnerability. The overhead of the patch is evaluated using simulation as well as an ESP32-WROVER-E development board. We showed that in the simulation with 32 general purpose registers the overhead for the CoreMark benchmark ranges between 0.1% and 0.4%. On the ESP32 that uses an Xtensa LX6 core with 64 general purpose registers the overhead went down to below 0.01%. A worst-case scenario, modeled by a synthetic benchmark showed overheads up to 9.68%.”

At the end of the Introduction: You need on this paper's contributions to the research community.

We have modified this part in the introduction. It now clearly names the contributions of the original paper as well as the extended paper. It now reads as follows:

“This work is an extension to a paper first presented at the International Telecommunication Networks and Applications Conference 2022 (ITNAC 2022) [7]. The contributions of the original paper were the introduction of a new vulnerability that utilizes the window overflow exception handlers of the Xtensa LX architecture. Countermeasures were introduced to mitigate the vulnerability. One particular countermeasure that involves a small patch of the exception handlers was evaluated. With this extension we hope to provide a better introduction into the field as well as a more detailed discussion of the vulnerability. We also extended our evaluation by moving to a real board instead of relying on simulations, leading to unexpected results as well as an adaption to our benchmark methodology using a synthetic benchmark as an addition to the CoreMark benchmark. We also extended our discussion of the feasibility of the vulnerability in regards of memory safety measures of the ESP32 microcontroller.

At the end of the article: Future work?

With this extended paper this work is relatively self-contained. We presented an attack and discussed appropriate countermeasures and evaluated our solution with simulations as well as benchmarks on a real microcontroller. We have rewritten the Conclusion section and hope that this is now better reflected. The conclusion now reads as follows:

“This paper extended the contents of [7]. This previous paper introduced a new vulnerability that allows the attacker to use an unprotected stack pointer to manipulate arbitrary memory addresses. The paper demonstrated how this vulnerability can be used to disable Stack Canaries and even discussed possibilities to combine it with other attack techniques such as ROP. It introduced a low-cost software patch for this vulnerability and used simulations in combination with the CoreMark benchmark to evaluate its overhead. The simulated Xtensa core only had 32 general purpose registers and the overhead ranged between 0.104% and 0.423%. It also showed the overhead for the exception handlers only which increased by 36.60%. These results were also included in this paper.

This paper extended the content by using a ESP32-WROVER-E development board for evaluation instead of simulations. This board uses two Xtensa LX6 cores, each with 64 general purpose registers. We believe this difference led to the significant differences in our measured results. The overhead of the patch measured for the microcontroller was between 0.0021% and 0.0065%. Additionally, a new benchmark was developed to showcase the worst-case scenario. It was designed to maximize the occurrence of window overflows, but can also scale and represent larger programs. In the worst case we showed that we were able to get up to 9.68% overhead, which is still far below the 36.60% measured in the simulation. Limits of the attack as well as defense mechanisms were discussed in detail.

In conclusion, the presented vulnerability can be a threat to systems that may have a buffer overflow vulnerability and insufficient protection. Our software patch should be easy to apply to existing systems with negligible consequences to the systems performance. It is also easy to integrate in an existing code base to protect systems. In the future, the vulnerability will hopefully be resolved by replacing vulnerable devices either with devices that are patched, or by devices using the next generation of Xtensa cores that do not contain the vulnerability anymore.”

Reviewer 3 Report

In this paper, the authors extend a previous paper exploiting a window overflow in an ESP32 microcontroller.

The authors provide a detailed discussion of this vulnerability and they propose and evaluate a set of mitigation techniques.

The paper covers an interesting topic, it is very well organized, and its English is generally well-written. However, the effective contribution is unclear and it should be better explained.

The authors are encouraged to check the following comments:

- The title should not be the same as the previous paper. The authors should focus on the additional contribution of this paper and the title should highlight this contribution. 

- The abstract should include a structure such as 1-context, 2-problem/opportunity, 3-proposal/contribution and 4-main results and conclusions. The presented abstract should be improved regarding (1) and (2) to explain what is the starting point of this research in order to present in (3) the contribution. In (4) no main results are presented.

- The abstract refers that it is presented a mitigation technique and it is evaluated the overhead of the mitigation techniques. The remaining mitigation techniques were presented by other authors?

- In the introduction, “Stack Canaries” is not introduced

- In the document, authors should use more formal language: e.g. instead of “doesn’t” it should be “does not”, “don’t” should be “do not”. 

. Also, if a section is a defined section, e.g. “Section 1”, the “s” should be capitalised.

- In Section 2, the ROP acronym should not be extended, since it was in Section 1

- the document seems to benefit if the contents of Section 4 are presented before Section 3, and it should be considered to merge both sections into one.

- Authors should use block diagrams and schematics to show the procedures and flows (e.g. it would be important in  Sections 4 with a figure such as Fig. 4). Section 5 could also benefit from diagrams and schematics to present functions and procedures.

- In line 240, instead of “it’s” it should be “its”

- Listing in line 288 has no number

- the word “Countermeasure” in the section title should be plural since more than one mechanism is detailed

- In the conclusions section the authors say that they “presented a new vulnerability targeting the Xtensa LX architecture” however the vulnerability was already presented in the previous paper, and thus it is not new.

- Table 1 and Table 2 are copied from the previous paper. This should not be presented since it is not a contribution from this paper. Authors should focus on the differential contribution regarding their last work.

- The conclusion should be better detailed in results, highlighting the differential contributions from the previous paper.

Detailed within the comments and suggestions for authors.

Author Response

Dear Reviewer,

Thank you very much for your review. We hope you will be pleased with our revision. Please find below our responses to your comments.

- The title should not be the same as the previous paper. The authors should focus on the additional contribution of this paper and the title should highlight this contribution.

We have adapted the title of the paper to better fit the content of the extended paper. The new title is: “Through the Window: Exploitation and Countermeasures of the ESP32 Register Window Overflow”

- The abstract should include a structure such as 1-context, 2-problem/opportunity, 3-proposal/contribution and 4-main results and conclusions. The presented abstract should be improved regarding (1) and (2) to explain what is the starting point of this research in order to present in (3) the contribution. In (4) no main results are presented.

The abstract has been rewritten according to (1) – (4). The abstract now reads as follows:

“With the increasing popularity of IoT (Internet-of-Things) devices their security becomes a more and more important issue. Buffer overflow vulnerabilities are known for decades but are still relevant, especially for embedded devices where certain security measures cannot be implemented due to hardware restrictions or simply due to their impact on performance. Therefore, many buffer overflow detection mechanisms check for overflows only before critical data is used. All data that an attacker could use for his own purposes can be considered critical. It is therefore essential that all critical data is checked between writing a buffer and its usage. This paper presents a vulnerability of the ESP32 microcontroller, which is used in millions of IoT devices, that is based on a pointer that is not protected by classic buffer overflow detection mechanisms like Stack Canaries, or Shadow Stacks. This paper discusses the implications of the vulnerability and presents mitigation techniques, including a patch, that fixes the vulnerability. The overhead of the patch is evaluated using simulation as well as an ESP32-WROVER-E development board. We showed that in the simulation with 32 general purpose registers the overhead for the CoreMark benchmark ranges between 0.1% and 0.4%. On the ESP32 that uses an Xtensa LX6 core with 64 general purpose registers the overhead went down to below 0.01%. A worst-case scenario, modeled by a synthetic benchmark showed overheads up to 9.68%.”

- The abstract refers that it is presented a mitigation technique and it is evaluated the overhead of the mitigation techniques. The remaining mitigation techniques were presented by other authors?

Thank you very much for pointing this out. The rewritten abstract now also mentions multiple mitigation techniques. In the previous version we only considered the software patch as a countermeasure which caused this inconsistency.

- In the introduction, “Stack Canaries” is not introduced

Thank you for noticing this oversight of ours. We have fixed that and the part now reads as follows:

“In addition, we describe how this attack can be used to bypass Stack Canaries and, under rare conditions, be extended to a ROP attack. Stack Canaries are a protection against stack buffer overflows that insert a guard word after local variables in a stack frame. This guard word is checked for modification before the function returns. A register window overflow can be triggered after a stack buffer overflow that accesses data that was manipulated by the said buffer overflow.”

- In the document, authors should use more formal language: e.g. instead of “doesn’t” it should be “does not”, “don’t” should be “do not”.

Thank you for this remark. We agree that a more formal language is appropriate and have fixed all occurrences you pointed out.

Also, if a section is a defined section, e.g. “Section 1”, the “s” should be capitalised.

We have fixed this at the end of the Introduction.

- In Section 2, the ROP acronym should not be extended, since it was in Section 1

We have removed the acronym extension.

- the document seems to benefit if the contents of Section 4 are presented before Section 3, and it should be considered to merge both sections into one.

Sections 3 and 4 have been swapped.

- Authors should use block diagrams and schematics to show the procedures and flows (e.g. it would be important in  Sections 4 with a figure such as Fig. 4). Section 5 could also benefit from diagrams and schematics to present functions and procedures.

Two new figures were introduced (Figure 2 and Figure 4 in the revised article) to hopefully help to better understand the contents of sections 4 and 5. Sadly, we were not able to find a good fit for a figure similar to the original Figure 4 which was suggested by you.

- In line 240, instead of “it’s” it should be “its”

Fixed.

- Listing in line 288 has no number

Fixed.

- the word “Countermeasure” in the section title should be plural since more than one mechanism is detailed

Thank you for pointing this out. We have changed the section title accordingly.

- Table 1 and Table 2 are copied from the previous paper. This should not be presented since it is not a contribution from this paper. Authors should focus on the differential contribution regarding their last work.

As this is an extended paper and not a completely new work we think it is appropriate to present the original results. Without these, it would be more complicated to talk about the differences between the simulation and ESP32 results. We therefore kept the tables as part of this extension.

- In the conclusions section the authors say that they “presented a new vulnerability targeting the Xtensa LX architecture” however the vulnerability was already presented in the previous paper, and thus it is not new.

- The conclusion should be better detailed in results, highlighting the differential contributions from the previous paper.

We have rewritten the conclusion section which now includes distinct conclusions of the original paper as well as conclusions of the extension. It now reads as follows:

“This paper extended the contents of [7]. This previous paper introduced a new vulnerability that allows the attacker to use an unprotected stack pointer to manipulate arbitrary memory addresses. The paper demonstrated how this vulnerability can be used to disable Stack Canaries and even discussed possibilities to combine it with other attack techniques such as ROP. It introduced a low-cost software patch for this vulnerability and used simulations in combination with the CoreMark benchmark to evaluate its overhead. The simulated Xtensa core only had 32 general purpose registers and the overhead ranged between 0.104% and 0.423%. It also showed the overhead for the exception handlers only which increased by 36.60%. These results were also included in this paper.

This paper extended the content by using a ESP32-WROVER-E development board for evaluation instead of simulations. This board uses two Xtensa LX6 cores, each with 64 general purpose registers. We believe this difference led to the significant differences in our measured results. The overhead of the patch measured for the microcontroller was between 0.0021% and 0.0065%. Additionally, a new benchmark was developed to showcase the worst-case scenario. It was designed to maximize the occurrence of window overflows, but can also scale and represent larger programs. In the worst case we showed that we were able to get up to 9.68% overhead, which is still far below the 36.60% measured in the simulation. Limits of the attack as well as defense mechanisms were discussed in detail.

In conclusion, the presented vulnerability can be a threat to systems that may have a buffer overflow vulnerability and insufficient protection. Our software patch should be easy to apply to existing systems with negligible consequences to the systems performance. It is also easy to integrate in an existing code base to protect systems. In the future, the vulnerability will hopefully be resolved by replacing vulnerable devices either with devices that are patched, or by devices using the next generation of Xtensa cores that do not contain the vulnerability anymore.”

Round 2

Reviewer 3 Report

Since the last review, the authors improved the document considering the comments addressed. However, the paper still presents limitations in content and contribution. The authors are encouraged to check the following comments:

- Listing 2 is exactly the same as listing 2 of the previously published paper. The same happens with tables I and II. These are not novel contributions of this paper and thus, I suggest the authors (1) remove listing 2 and reference previous work, explaining shortly the test created in the previous paper to assess the overflow exception handlers and (2) present a unique table merging the results of tables 1, 2, and 3. The discussion around subsections 7.1 and 7.2 should be removed. These discussions were taken in the previous paper and thus, authors can provide a resumed version.

- This paper should be an extended version of a previous paper, highlighting the new contributions made by the authors. This should not be a copy (ipsis verbis) of the previous work. Expressions such as “To our surprise the results for the two compilers were very different. The results for xt-clang are shown in Table 1 and for xcc in Table 2” are not admissible, since this is the same sentence of the previous paper. Expressions such as “We evaluated our countermeasure using the simulation of a Xtensa LX7 core with 32 physical registers as well as a ESP32-WROVER-E development board with two Xtensa LX6 cores with 64 physical registers” is misleading since you did not evaluate those in this paper but in a previous publication. This is an example of the inconsistency found between this and the previous work. Although the authors provided a revised version of the abstract and introduction, the remaining content of the paper has no change in this respect.

- Table 3 seems not correctly presented, since there are missing columns. Also, how do these results relate to Tables 2 and 3?

- The number of sections could be reduced to make the paper more understandable. Section 4 could be inserted inside Section 5 (as just a paragraph). Subsection “5.2. Regarding MPU and MMU Protection” should have the “regarding” removed. Subsections in section 5 could be arranged for the document to present fewer unnecessary divisions. The content of sections 7.1 and 7.2 should not be included as sections and the focus should be directed to 7.3. Section 7.3.1 should not exist since there is no 7.3.2.

- Authors should avoid expressions such as “In our opinion…” since this is a scientific paper and not an opinion document.

Moderate editing is required as highlighted in the comments to authors section.

Author Response

Dear Reviewer,

Thank you very much again for your review. Please find our response to your comments below.

- Listing 2 is exactly the same as listing 2 of the previously published paper. The same happens with tables I and II. These are not novel contributions of this paper and thus, I suggest the authors (1) remove listing 2 and reference previous work, explaining shortly the test created in the previous paper to assess the overflow exception handlers and

Thank you very much for pointing out that Listing 2 was already present in the previously published paper. We have now correctly referenced it. We decided to leave Listing 2 in the paper as it shows the countermeasure that is described in section 6.1 and evaluated in section 7 and is therefore essential for the understanding of the article. Also, compared to the previously published paper, the description of Listing 2 has been rewritten and extended by 6.1.1. Therefore, we think its inclusion is justified.

(2) present a unique table merging the results of tables 1, 2, and 3.

We have discussed the possibility to merge all three tables together. Sadly, we came to no satisfying conclusion. This is due to the fact that Table 1 and Table 2 are presenting the evaluation results that were taken from the previous publication and Table 3 shows our measured results on the microcontroller, which is part of the extended paper. We could remove parts of Table 1 and Table 2 and only leave the parts that are also presented in Table 3 and merge them together but we think this would not benefit the article. The reason is that Table 1 and Table 2 present measurements in clock cycles, while Table 3 present measurements in time and we don’t want to mix these together. In results, only the percentage overhead is comparable between the tables. We have modified the paragraph to subsection 7.2 to highlight the differences between the results of the simulation and the measurements done on the microcontroller. It now reads as follows:

“Naturally, the evaluation shown in Table 3 also misses the other information we received from the profiling tool of the simulator, like the exact number of window overflow exceptions and their execution time. We see however a drastically reduced overhead compared to the simulations. Even the largest overhead of 0.0065% is drastically lower than the best case for the simulation with 0.024%. when only comparing results from the same compiler family, the differences are even larger, with 0.104% being the best simulation result.”

(2) ….The discussion around subsections 7.1 and 7.2 should be removed. These discussions were taken in the previous paper and thus, authors can provide a resumed version.

Section 7.2 was not part of the previously published paper. The reasons for the differences between tables 1,2 and Table 3 are described in section 7.2.

- This paper should be an extended version of a previous paper, highlighting the new contributions made by the authors. This should not be a copy (ipsis verbis) of the previous work. Expressions such as “To our surprise the results for the two compilers were very different. The results for xt-clang are shown in Table 1 and for xcc in Table 2” are not admissible, since this is the same sentence of the previous paper.

We rephrased and shortened the description of Table 1 and Table 2. It now reads as follows:

“The results for the two compilers were very different; for xt-clang they are shown in Table 1 and for xcc in Table 2 the top half shows the number of different window overflows that occurred, while the bottom half displays the base number of clock cycles without the protection mechanism, as well as the absolute and relative overhead introduced by it. While the overhead for the exception handler itself stays almost constant around 36.3%, the overall overhead for the application greatly varies from 0.024% - 0.036% for xt-clang up to 0.104% - 0.423% for xcc, depending on the level of optimization.

These large differences can be explained by looking at the differences in number of window overflows for the different configurations. While xcc shows great improvements with higher optimization levels, the number of window overflows (and with that also the absolute overhead) stays almost constant. In contrast, xt-clang heavily decreases the number of overflows with higher optimization levels (e.g. by inlining functions) resulting in smaller absolute overhead.”

Expressions such as “We evaluated our countermeasure using the simulation of a Xtensa LX7 core with 32 physical registers as well as a ESP32-WROVER-E development board with two Xtensa LX6 cores with 64 physical registers” is misleading since you did not evaluate those in this paper but in a previous publication. This is an example of the inconsistency found between this and the previous work. Although the authors provided a revised version of the abstract and introduction, the remaining content of the paper has no change in this respect.

We have added the following sentence to the paragraph for clarification:

“The simulation results were part of the previous publication [7].”

- Table 3 seems not correctly presented, since there are missing columns. Also, how do these results relate to Tables 2 and 3?

We have added an additional column to Table 3, which hopefully now is complete.

- The number of sections could be reduced to make the paper more understandable. Section 4 could be inserted inside Section 5 (as just a paragraph).

We have integrated Section 4 into Section 5 as the first subsection, right before the example attack is explained.

Subsection “5.2. Regarding MPU and MMU Protection” should have the “regarding” removed.

The wording has been adapted according to your suggestion.

Subsections in section 5 could be arranged for the document to present fewer unnecessary divisions.

In our opinion Section 5 (now Section 4) is the core of the article and therefore the most complex one. The different subsections help to divide the content and we think removing subsection would not help the readability of the article. We also don’t see a better arrangement for the subsections. We would therefore like to keep this section in its current form.

The content of sections 7.1 and 7.2 should not be included as sections and the focus should be directed to 7.3.

We will keep sections 7.1 and 7.2 in the paper for the reasons explained above.

Section 7.3.1 should not exist since there is no 7.3.2.

Thank you for this remark. We have removed it.

- Authors should avoid expressions such as “In our opinion…” since this is a scientific paper and not an opinion document.

We have removed this phrase at two occurrences.

Round 3

Reviewer 3 Report

Since the last review, the authors improved the document taking into account the comments addressed. However, the paper still presents limitations in content. The authors are encouraged to check the following comments:

- Section 5.1 shouldn’t exist since there is no Section 5.2

- Subsection 5.1.1 shouldn’t exist since there is no Subsection 5.1.2

- Authors should also proofread the entire document to avoid any phrase repeated “ipsis verbis” from the last publication.

Note:

I disagree with the authors on the discussion regarding the contents of Sections 7.1 and 7.2. I consider that if the content is already published in another paper it should not be explained/detailed in this one. However, I consider that this does not affect the main contribution of this paper, and thus, I submit my review in these terms.

Detailed above.

Author Response

Dear Reviewer,

thank you for the review. Please find below our answers to your comments.

- Section 5.1 shouldn’t exist since there is no Section 5.2

- Subsection 5.1.1 shouldn’t exist since there is no Subsection 5.1.2

We have removed Section 5.1 and Subsection 5.1.1 as recommended. However, we kept the headings as paragraphs as we think it improves readability.