Timeline for How do interpreters avoid stack buffer overflow-related undefined behavior and exploits?
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 19, 2023 at 2:31 | history | edited | anon | CC BY-SA 4.0 |
added 91 characters in body
|
| Sep 8, 2023 at 10:42 | answer | added | Matthieu M. | timeline score: 3 | |
| Sep 8, 2023 at 6:18 | comment | added | tarzh |
I can confirm GNU-R checks the stack size in recursive functions and before large alloca, and fails gracefully before the stack gets too big. The relevant functions are R_CheckStack and R_CheckStack2
|
|
| Sep 7, 2023 at 23:53 | answer | added | Chris Dodd | timeline score: 3 | |
| Sep 7, 2023 at 16:14 | answer | added | Eric Lippert | timeline score: 6 | |
| Aug 19, 2023 at 2:24 | comment | added | Nate Eldredge | Since interpreted languages usually feature memory safety, e.g. where out-of-bounds accesses are guaranteed to cause a runtime error instead of undefined behavior, this checking is probably being done anyway. | |
| Aug 19, 2023 at 2:23 | comment | added | Nate Eldredge | We have to distinguish between two different senses of the word "stack overflow". One is where we simply use more total stack than the OS allocates to us (by recursing too deep, etc). This may crash the interpreter, but it does not corrupt memory and is not otherwise exploitable. The other is where we overflow a particular buffer on the stack and write beyond its end. This can be exploited, but is preventable if the interpreter simply does bounds checking on its accesses, or on all those whose indices may be "tainted" by the user's code. | |
| Aug 18, 2023 at 22:22 | vote | accept | anon | ||
| Aug 18, 2023 at 22:21 | comment | added | anon | @Barmar I worked on an R interpreter based on GNU R recently and it really seemed like it was using the native stack. I might be completely wrong though, and don't have any experience with other interpreters, hence the question. | |
| Aug 18, 2023 at 22:17 | comment | added | anon | @kaya3 I don't think I fully understand your first question, but I'm asking about interpreters because they're the typical kind of programs that arbitrarily recurse in a way that cannot be predicted (halting problem / Rice's theorem), so you have to be reactive rather than proactive. For the last unsubstantiated claims, they're just generalized guesses from my limited experience, I'm not claiming that any of this is true. | |
| Aug 18, 2023 at 22:13 | comment | added | Barmar | Interpreters are often implemented as state machines, so there's little recursion in them. The language stack is not the hardware stack, it's just a data structure managed by the language (e.g. a linked list). I guess this is your "reified stack" case. | |
| Aug 18, 2023 at 19:02 | answer | added | Michael Homer♦ | timeline score: 3 | |
| Aug 18, 2023 at 18:10 | comment | added | user1030 | "but would require a fallback" -- or the VM just does not support platforms that lack that capability. | |
| Aug 18, 2023 at 18:06 | review | Close votes | |||
| Aug 19, 2023 at 1:33 | |||||
| Aug 18, 2023 at 16:57 | comment | added | kaya3 | Is there any reason to expect that different approaches would be needed to protect against these flaws in interpreters compared to other types of software? There are several assumptions in your question (e.g. stack overflows being UB in the host language, reified stacks being supposedly slower, OS segfault handlers being unreliable) which are unsubstantiated. | |
| Aug 18, 2023 at 16:50 | history | asked | anon | CC BY-SA 4.0 |