4 ms·

Hey. In your C code, you write to memory beyond what you malloc'd. You malloc'd 9 bytes for 'pw', but later do "pw[9] = '\0'", which accesses the 10th byte, w

by matmann2001 8y ago

Hey. In your C code, you write to memory beyond what you malloc'd. You malloc'd 9 bytes for 'pw', but later do "pw[9] = '\0'", which accesses the 10th byte, which doesn't belong to you.

w0mbat 8y ago
Yes, that jumped off the page at me too, and distracted me from the rest of the article.
- matmann2001 8y ago
  Especially given the topic, I kept jumping around to see if it was intentional. Like maybe they would use these RE tools to exploit it.
blattimwind 8y ago
malloc allocates aligned memory [1], so technically it's correct that he writes past the allocated memory, but technically it's also impossible for that write to fail or for that write to overwrite something else. [1] bonus point: for what kind of alignment? (The minimum is quite well specified, for C standards)
- spieglt 8y ago
  https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html https://www.gnu.org/software/libc/manual/html_node/Aligned-M... "The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems)." I was about to say, "what if they're on a 32-bit system and so were only allocated one 8-byte block?" but then realized that since they'd requested 9 bytes, they'd be given two 8-byte blocks, or one 16-byte block on a 64-bit system. Is that right?
  - spieglt 8y ago
    Well, I guess alignment doesn't say anything about how large of a block is allocated.... And this is the clearest source I can find, which says 32 bytes. https://prog21.dadgum.com/179.html https://prog21.dadgum.com/179.html
    - blattimwind 8y ago
      > Well, I guess alignment doesn't say anything about how large of a block is allocated It tells you where something can't be, and because virtual memory is allocated in whole pages the "padding" so to speak will always be accessible. There's also the obvious truism that if you can access something in a cache line, all addresses in the cache line are safe to access. (Vectorized algorithms frequently implicitly rely on this for short reads, IOW there is no way reading a 128 or 256 bit vector can fault if just reading the first lane would not fault).
      - saagarjha 8y ago
        > Vectorized algorithms frequently implicitly rely on this for short reads This is extremely processor-dependent and you should not be writing C if you’re relying on this.
        blattimwind 8y ago
        > This is extremely processor-dependent No, it's not. > you should not be writing C if you’re relying on this. Luckily you are in no position to tell anyone what they should or shouldn't do.
        saagarjha 8y ago
        Sorry, I misunderstood the context of that statement and was thought you were talking about vectorized algorithms exploiting out-of-bounds reads in general, which is pretty dependent on the processor as to when it will work (depending on how page boundaries and cache lines are set up). And I didn't really mean my statement about using C in the prescriptive way you seem to have taken it: I was merely trying to say that you should probably be using assembly in this case, because you are relying on details of your processor that your compiler is likely to be unaware about and may penalize you for. For example, the vectorized string routines in libSystem do overshoot the end of the string because they use pcmpeqb, and it is written in assembly because it relies on alignment guarantees that are difficult to express in C. Plus it guarantees vectorization ;)
- saagarjha 8y ago
  For Glibc on Linux, I believe this is 32 bytes. I think musl does 16 bytes, as does libSystem on macOS.
- sgillen 8y ago
  Still feels dirty though doesn't it? Would never want to rely on this fact..
  - saagarjha 8y ago
    Yeah, this is undefined behavior and your compiler might bite you for it.
- jmts 8y ago
  Then one day you come back and resize the array to a multiple of the memory alignment, and BAM! Off-by-one errors, or even vulnerabilities. Or you enable more strict build settings and BAM! You have to go back and deal with all the places your code allows you to write off the end of a buffer because you just didn't give a damn before.
Icyphox 8y ago
Ah my bad. I’ll make sure to fix it. Sorry about that.

Hey. In your C code, you write to memory beyond what you malloc'd. You malloc'd 9 bytes for 'pw', but later do "pw[9] = '\0'", which accesses the 10th byte, which doesn't belong to you.

w0mbat 8y ago

Yes, that jumped off the page at me too, and distracted me from the rest of the article.

matmann2001 8y ago
Especially given the topic, I kept jumping around to see if it was intentional. Like maybe they would use these RE tools to exploit it.

blattimwind 8y ago

malloc allocates aligned memory [1], so technically it's correct that he writes past the allocated memory, but technically it's also impossible for that write to fail or for that write to overwrite something else. [1] bonus point: for what kind of alignment? (The minimum is quite well specified, for C standards)

spieglt 8y ago
https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html https://www.gnu.org/software/libc/manual/html_node/Aligned-M... "The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems)." I was about to say, "what if they're on a 32-bit system and so were only allocated one 8-byte block?" but then realized that since they'd requested 9 bytes, they'd be given two 8-byte blocks, or one 16-byte block on a 64-bit system. Is that right?
- spieglt 8y ago
  Well, I guess alignment doesn't say anything about how large of a block is allocated.... And this is the clearest source I can find, which says 32 bytes. https://prog21.dadgum.com/179.html https://prog21.dadgum.com/179.html
  - blattimwind 8y ago
    > Well, I guess alignment doesn't say anything about how large of a block is allocated It tells you where something can't be, and because virtual memory is allocated in whole pages the "padding" so to speak will always be accessible. There's also the obvious truism that if you can access something in a cache line, all addresses in the cache line are safe to access. (Vectorized algorithms frequently implicitly rely on this for short reads, IOW there is no way reading a 128 or 256 bit vector can fault if just reading the first lane would not fault).
    - saagarjha 8y ago
      > Vectorized algorithms frequently implicitly rely on this for short reads This is extremely processor-dependent and you should not be writing C if you’re relying on this.
      - blattimwind 8y ago
        > This is extremely processor-dependent No, it's not. > you should not be writing C if you’re relying on this. Luckily you are in no position to tell anyone what they should or shouldn't do.
        saagarjha 8y ago
        Sorry, I misunderstood the context of that statement and was thought you were talking about vectorized algorithms exploiting out-of-bounds reads in general, which is pretty dependent on the processor as to when it will work (depending on how page boundaries and cache lines are set up). And I didn't really mean my statement about using C in the prescriptive way you seem to have taken it: I was merely trying to say that you should probably be using assembly in this case, because you are relying on details of your processor that your compiler is likely to be unaware about and may penalize you for. For example, the vectorized string routines in libSystem do overshoot the end of the string because they use pcmpeqb, and it is written in assembly because it relies on alignment guarantees that are difficult to express in C. Plus it guarantees vectorization ;)
saagarjha 8y ago
For Glibc on Linux, I believe this is 32 bytes. I think musl does 16 bytes, as does libSystem on macOS.
sgillen 8y ago
Still feels dirty though doesn't it? Would never want to rely on this fact..
- saagarjha 8y ago
  Yeah, this is undefined behavior and your compiler might bite you for it.
jmts 8y ago
Then one day you come back and resize the array to a multiple of the memory alignment, and BAM! Off-by-one errors, or even vulnerabilities. Or you enable more strict build settings and BAM! You have to go back and deal with all the places your code allows you to write off the end of a buffer because you just didn't give a damn before.

Icyphox 8y ago

Ah my bad. I’ll make sure to fix it. Sorry about that.