Add use-after-free (UaF) section (#242) #267
Conversation
g-kouv
left a comment
g-kouv
left a comment
There was a problem hiding this comment.
Thanks for the contribution, @tarcisiofischer!
It looks good to me overall, with some suggestions (most of them are really minor).
Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: all files reviewed, 16 unresolved discussions (waiting on @tarcisiofischer)
book.md line 513 at r1 (raw file):
## Use After Free (UaF) An use-after-free (UaF) occurs when a variable is used (read and/or written)
Nit: "A use-after-free"
book.md line 513 at r1 (raw file):
## Use After Free (UaF) An use-after-free (UaF) occurs when a variable is used (read and/or written)
Can you add use-after-free to the index, with \index{use-after-free}?
book.md line 514 at r1 (raw file):
An use-after-free (UaF) occurs when a variable is used (read and/or written) after it has been freed. Although some UaF may be just harmless bugs that leads
Nit: leads -> lead
book.md line 518 at r1 (raw file):
they can potentially result in data being poisoned to change the intended program flow. There are many possibilities on how this can happen, some of them depend on how the software's memory allocator manages it's data. For example,
Nit: I don't think "the software's" is necessary in this context.
book.md line 521 at r1 (raw file):
if the attacker can trick the allocator to return the same address for two different allocations (see example below), that could lead to controllable data. The attacker's goal of taking advantage of an UaF can also vary. From simply
Nit: "an UaF" -> "a UaF".
book.md line 521 at r1 (raw file):
if the attacker can trick the allocator to return the same address for two different allocations (see example below), that could lead to controllable data. The attacker's goal of taking advantage of an UaF can also vary. From simply
I'm not entirely sure what you want to say about the attacker's goal here - did you mean to talk about the technique/method instead? I can't parse the sentence starting with "From simply..", the sentence feels incomplete. Is this an example of what an attacker can achieve? It feels more like a method than a goal.
book.md line 523 at r1 (raw file):
The attacker's goal of taking advantage of an UaF can also vary. From simply changing booleans (e.g. is\_logged\_in) to function pointers that can corrupt the control flow, allowing the attacker to call unintended functions in the system.
"Call unintended functions" sounds a bit strange, I suggest:
"allowing the attacker to call functions they weren't supposed to".
book.md line 528 at r1 (raw file):
internet. A summary of heap exploiting techniques [can be found here](https://heap-exploitation.dhavalkapil.com/attacks). But for the sake of completeness, a very simple example code is shown bellow in this
Typo: bellow -> below
book.md line 529 at r1 (raw file):
[can be found here](https://heap-exploitation.dhavalkapil.com/attacks). But for the sake of completeness, a very simple example code is shown bellow in this textbook. The exploit below may not work in any system, as it assumes that
Nit: I would omit "in this textbook".
book.md line 529 at r1 (raw file):
[can be found here](https://heap-exploitation.dhavalkapil.com/attacks). But for the sake of completeness, a very simple example code is shown bellow in this textbook. The exploit below may not work in any system, as it assumes that
Nit: any -> every.
book.md line 579 at r1 (raw file):
The example below tricks the software into thinking the user is logged in, by
example -> example execution?
book.md line 583 at r1 (raw file):
auth admin
I wonder if somehow separating the input visually here might be clearer - perhaps adding a prompt like '>' in the program would help? (You could also play with formatting but @kbeyls probably has better suggestions regarding formatting).
book.md line 596 at r1 (raw file):
1) 'auth admin' will allocate the auth\_t structure for the first time. At this point, the user has a name, but is not authorized (logged\_in is false). 2) 'reset' will free the memory. service (...) will allocate a new string
You can also mention here that the memory is freed but the auth pointer not set to null, so it remains dangling.
book.md line 597 at r1 (raw file):
this point, the user has a name, but is not authorized (logged\_in is false). 2) 'reset' will free the memory. service (...) will allocate a new string which, if it's initialized at the same memory location as auth, can be used to
initialized -> allocated.
Technically, we're not changing data in the auth_t structure. It's on reading from the auth pointer in 'login' where the error happens - the pointer doesn't point to an auth_t structure anymore. I would say something like:
- ... will allocate a new string, potentially at the same address where the
auth_tstructure was previously allocated. - 'login' will use the dangling
authpointer. If this memory has been reallocated to the attacker controlled string, it will appear as if the field "name" is set to
aaaaaaaaa0aaaaaaaaa0aaaaaaaaa012 and the boolean logged_in to true. - ..
(Hope that makes sense, it needs formatting and polishing).
book.md line 603 at r1 (raw file):
aaaaaaaaa0aaaaaaaaa0aaaaaaaaa012 and the boolean logged\_in to true (1). Therefore, the next call to login will say that the user is logged in. 4) 'login' will show that the user is logged in (it shouldn't)
Nit: I would remove "(it shouldn't). There's also a missing '.'
book.md line 613 at r1 (raw file):
[another section](#preventing-and-detecting-memory-errors). And finally, fuzzing (generating random inputs) can also be useful, potentially used at the same time as other tools. In the specific cases where UaF is used to
I think the mention of pointer authentication here is redundant, since you mention it in the next paragraph (where it fits better, since you are talking about limiting exploitability).
|
@all-contributors please add @tarcisiofischer for code |
|
I've put up a pull request to add @tarcisiofischer! 🎉 |
|
Thanks for the review! |
JLouisKaplan-Arm
left a comment
JLouisKaplan-Arm
left a comment
There was a problem hiding this comment.
This is a nice read, thanks! Added some small optional nits/suggestions.
Reviewable status: 0 of 1 files reviewed, 22 unresolved discussions (waiting on @g-kouv, @kbeyls, and @tarcisiofischer)
book.md line 515 at r2 (raw file):
A use-after-free\index{use-after-free} (UaF) occurs when a variable is used (read and/or written) after it has been freed. Although some UaF may be just harmless bugs that lead to weird software behavior or application crashes, there are some cases where
nit: not sure I agree that weird software behavior or application crashes are harmless bugs :)
Potential alternative wording (just a suggestion):
"""
Although some cases of UaF may just lead to unexpected software behavior or crashes, other cases may enable attackers to poison data and thereby alter program flow.
"""
book.md line 518 at r2 (raw file):
they can potentially result in data being poisoned to change the intended program flow. There are many possibilities on how this can happen, some of them depend on how the memory allocator manages it's data. For example,
nit: "manages it's data" -> "manages its data"
book.md line 522 at r2 (raw file):
different allocations (see example below), that could lead to controllable data. There are many sources of information regarding how to exploit UaF over the
small nit: suggest either "on the internet" or just removing "over the internet" completely.
book.md line 603 at r2 (raw file):
logged\_in to true. Detecting use-after-frees is usually not an easy task, as it depend not only on
nit: could use your acronym from earlier here - UaF?
book.md line 606 at r2 (raw file):
user inputs, but sometimes also on the execution flow. It can get even more complicated in multi-threaded environments. Some UaF detectors intercept calls for delete / free to inject a known value to the variables and then run the
nit: calls to?
book.md line 618 at r2 (raw file):
avoid reusing specific memory locations. On top of that, decreasing relevance of UaF for attackers can be another interesting perspective (meaning, even if an UaF is present, decreasing the likelihood of it being exploitable). For
nit: "an UaF" -> "a UaF"
kbeyls
left a comment
kbeyls
left a comment
There was a problem hiding this comment.
Thank you very much for this contribution @tarcisiofischer !
I like it a lot.
Reviewable status: 0 of 1 files reviewed, 32 unresolved discussions (waiting on @g-kouv and @tarcisiofischer)
book.md line 514 at r2 (raw file):
A use-after-free\index{use-after-free} (UaF) occurs when a variable is used (read and/or written) after it has been freed. Although some UaF may be just harmless bugs that lead
I was a bit confused about "when a variable is used after is has been freed."
It made me wonder if UaF only applies to variables on the heap, which are explicitly allocated using some form of malloc/new/free/delete, or similar in non-C/C++ programming languages.
Does Use-after-Free also apply to variables that live on the stack?
I think it would be worthwhile to spend a few sentences to answer/clarify this.
(Another side thought I have here is use-after-free impossible in garbage-collected languages? What about languages that use reference counting, such as Swift? In other words, what are the necessary conditions for use-after-free to be possible?)
book.md line 520 at r2 (raw file):
depend on how the memory allocator manages it's data. For example, if the attacker can trick the allocator to return the same address for two different allocations (see example below), that could lead to controllable data.
"(see example below)" -> if you use the example div class, you could explicitly refer to it.
Line 379 in 5094cff
book.md line 529 at r2 (raw file):
calling malloc+free+malloc will return the same pointer in the two calls.
I'd make this an explicit examples, for example, by adding something like
::: {.example #ex:uaf-simple-example
caption="A simple use-after-free example"}
book.md line 529 at r2 (raw file):
calling malloc+free+malloc will return the same pointer in the two calls.
Also, since this is C code, probably best to indicate that by writing
```c
IIRC, that should automatically highlight the code correctly.
book.md line 546 at r2 (raw file):
if (strncmp(line, "auth ", 5) == 0) { auth = (struct auth_t*)malloc(sizeof(struct auth_t)); memset(auth, 0, sizeof(struct auth_t)); // Memory is only set to 0 here, not on free[1]
I'm guessing this long line will not display very well, as it will be wrapped.
Maybe it'd be better to put the comment on a line by itself above the memset line?
book.md line 564 at r2 (raw file):
// Usage: login else if (strncmp(line, "login", 5) == 0) { if (auth && auth->logged_in) { // Possible use-after-free
Also here, the comment is probably best placed on its own line to avoid wrapping the line in the various book output formats.
book.md line 603 at r2 (raw file):
logged\_in to true. Detecting use-after-frees is usually not an easy task, as it depend not only on
s/depend/depends/?
book.md line 605 at r2 (raw file):
Detecting use-after-frees is usually not an easy task, as it depend not only on user inputs, but sometimes also on the execution flow. It can get even more complicated in multi-threaded environments. Some UaF detectors intercept calls
I think the overview of mitigations against use-after-free attacks could be more balanced.
At the moment, it calls out MTE and pointer authentication, but does not point to examples
of UaF detectors. AFAIK, other mitigation techniques do include:
- allocators using different algorithms to reduce the probability of exploiting use-after-free (this might be a whole section of it's own?)
- It probably is worthwhile to also cover Type-aware allocation and deallocation functions , which explains the motivation for this feature at https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2719r5.html#a-concrete-use-case.
- languages that use garbage collection or reference counting might also be seen as a mitigation against use-after-free?
I'm sure I'm missing other mitigations worth covering too.
Anyway, it's probably best to not to try and address this comment in this PR, but keep that for another PR.
book.md line 609 at r2 (raw file):
software looking for crashes that include that value. Another useful tool for detecting UaF is Arm's MTE (Memory Tagging Extension), discussed in [another section](#preventing-and-detecting-memory-errors). And finally,
I think I'd refer to the section by using it's section number, using the following markdown syntax:
... discussed in section @sec:preventing-and-detecting-memory-errors.
You'll need to add
{ #sec:preventing-and-detecting-memory-errors }
to the line the introduces the referred to header to make this work:
## Preventing and detecting memory errors { #sec:preventing-and-detecting-memory-errors }
book.md line 622 at r2 (raw file):
while Pointer Authentication (PAC) can be used to sign pointers so that even if they get poisoned, they cannot be used (more details in [this section](#pointer-authentication)).
Similar remark as above: I'd use @sec:... to refer to the section.
tarcisiofischer
force-pushed
the
main
branch
from
dd19d0c to
ed27a58
Compare
|
All done. Thanks. |
tarcisiofischer
force-pushed
the
main
branch
from
92f5057 to
dbf20a8
Compare
kbeyls
left a comment
kbeyls
left a comment
There was a problem hiding this comment.
Thank you very much for the update @tarcisiofischer !
I think this is almost ready to merge.
I've left a number of nit-picky comments that I think could make the text a bit easier to read/process for the reader. But please feel free to disagree!
kbeyls
left a comment
kbeyls
left a comment
There was a problem hiding this comment.
LGTM, I just had one more very tiny nit-pick comment.
|
LGTM too, thanks! |
4 participants
Hey all.
This is a proposal section about "use after free", after I've noticed it appears appears only once in the text, currently, and "UaF" doesn't appear even once. It also seems related to #242 , so marking that issue in the commit message.
Please lmk what you think!
Thanks in advance.
This change is