From 9cf17517672991a5893ec3fa150b45149ee35954 Mon Sep 17 00:00:00 2001 From: Jack Bond-Preston Date: Thu, 5 Jan 2023 19:46:24 +0000 Subject: [PATCH] update cheri article --- _posts/cheri/2022-11-19-cheri.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/_posts/cheri/2022-11-19-cheri.md b/_posts/cheri/2022-11-19-cheri.md index bbf1e9d..110ed63 100644 --- a/_posts/cheri/2022-11-19-cheri.md +++ b/_posts/cheri/2022-11-19-cheri.md @@ -33,7 +33,7 @@ my_perfect_string: what a beautiful string works on my machine boss! code review +1, and merged... -...until our good friend Hubert Blaine Wolfeschlegelsteinhausenbergerdorff Sr. comes along. he emails me a strange error he's running into: +...until our good friend [Hubert Blaine Wolfeschlegelsteinhausenbergerdorff Sr.](https://en.wikipedia.org/wiki/Hubert_Blaine_Wolfeschlegelsteinhausenbergerdorff_Sr.) comes along. he emails me a strange error he's running into: {% highlight console %} $ ./membug @@ -42,11 +42,16 @@ hello Hubert Blaine Wolfeschlegelsteinhausenbergerdorff Sr. my_perfect_string: hausenbergerdorff Sr. {% endhighlight %} -***note:*** if you compile and run this on your machine, you may not get the same output. that's because we're invoking *undefined behaviour* here, so the compiler can kind of do whatever it wants. I'll always provide the output that demonstrates what I'm trying to show when giving examples like this. for what it's worth, I'm running `clang 10.0.0-4ubuntu1` with target `x86_64-pc-linux-gnu`. compilation options, the `Makefile`, and such are available code subdirectory of this article's source. +***note:*** if you compile and run this on your machine, you may not get the same output. that's because we're invoking *undefined behaviour* here, so the compiler can kind of do whatever it wants. I'll always provide the output that demonstrates what I'm trying to show when giving examples like this. for what it's worth, I'm running `clang 10.0.0-4ubuntu1` with target `x86_64-pc-linux-gnu`. compilation options, the `Makefile`, and such are available [code subdirectory of this article's source](https://github.com/jackbondpreston/jackbondpreston.github.io/tree/master/_posts/cheri/code). that's not supposed to happen! his name has spilled over into our `my_perfect_string[]` array! turns out our issue is that when we use `fgets(char *str, int count, FILE *stream)`, we've set the second parameter (`size`) to `1000` - but our `user_name[32]` array can only fit 32 characters (and the last of these should be a null terminator, so 31 usable characters). -`fgets()` fills up `user_name`, but it hasn't finished with the name yet! it doesn't care (or know) that `user_name` is full, it's just going to keep going until it finishes our user input, or reads 999 characters from standard input. thus it keeps mindlessly writing, overwriting the section memory we've used to store our precious perfect string (which happens to be immediately after `user_name`). let's take a look at the stack in GDB to see how this happens: +`fgets()` fills up `user_name`, but it hasn't finished with the name yet! it doesn't care (or know) that `user_name` is full, it's just going to keep going until it finishes our user input, or reads 999 characters from standard input. thus it keeps mindlessly writing, overwriting the section memory we've used to store our precious perfect string (which happens to be immediately after `user_name`). + +`fgets()` has a cousin, `gets(char *s)`, which is particularly poor with regards to memory safety, [and has largely been moved away from in modern C](https://linux.die.net/man/3/fgets): +> LSB deprecates `gets()`. POSIX.1-2008 marks `gets()` obsolescent. ISO C11 removes the specification of `gets()` from the C language, and since version 2.16, glibc header files don't expose the function declaration if the `_ISOC11_SOURCE` feature test macro is defined. + +let's take a look at the stack in GDB to see how this happens: {% highlight plaintext %} (gdb) b memdebug.c:7