bug of the day: a memcmp that only compares every fourth byte
-
bug of the day: a memcmp that only compares every fourth byte
@gsuberland@chaos.social what about an strncmp that doesn't stop at a null terminator
-
@dysfun essentially this:
int memcmp32(uint32_t* a, uint32_t* b, int words)
{
uint8_t sum = 0; // whoops
while(words--) {
sum |= *a++ ^ *b++;
}
return sum;
}@gsuberland yes, that's exactly what i thought
-
bug of the day: a memcmp that only compares every fourth byte
@gsuberland my bad. I misheard directions, and used AL when what the boss really wanted was AI.
-
@dysfun it's a constant time implementation if that helps
@dysfun@social.treehouse.systems @gsuberland@chaos.social
Hmm… is the issue casting 64-bit memory to an 8-bit char?
-
@gsuberland@chaos.social what about an strncmp that doesn't stop at a null terminator
@gsuberland@chaos.social ....the famous wii trucha bug is probably because broadon didn't understand the difference between strncmp and memcmp, in their own libc they do the same thing
-
@dysfun essentially this:
int memcmp32(uint32_t* a, uint32_t* b, int words)
{
uint8_t sum = 0; // whoops
while(words--) {
sum |= *a++ ^ *b++;
}
return sum;
} -
bug of the day: a memcmp that only compares every fourth byte
@gsuberland
It's not named allmemcmp for a reason. -
@gsuberland yes, that's exactly what i thought
@dysfun ehehehe
the code in question lucked out by never actually using it in a path that matters, but it's in a core lib for something security sensitive so easily could've ended up being bad
-
@dysfun ehehehe
the code in question lucked out by never actually using it in a path that matters, but it's in a core lib for something security sensitive so easily could've ended up being bad
@gsuberland yeah it lucked out by not having bit rotted yet
-
@dysfun@social.treehouse.systems @gsuberland@chaos.social
Hmm… is the issue casting 64-bit memory to an 8-bit char?
-
bug of the day: a memcmp that only compares every fourth byte
i blogged about the memcmp thing
-
i blogged about the memcmp thing
@gsuberland unrelated but shouldn't it be something like
*(a++) ^ *(b++)? -
@gsuberland unrelated but shouldn't it be something like
*(a++) ^ *(b++)?@mildsunrise probably yeah I'm tired lol
-
@mildsunrise probably yeah I'm tired lol
@mildsunrise wait no, cos (a++) would be equivalent to pre-increment
-
@mildsunrise wait no, cos (a++) would be equivalent to pre-increment
@mildsunrise but yeah it should be *a ^ *b and then separately incrementing
-
R relay@relay.infosec.exchange shared this topic
-
@mildsunrise wait no, cos (a++) would be equivalent to pre-increment
@gsuberland (a++) is post increment, pre increment would be (++a)
-
@gsuberland (a++) is post increment, pre increment would be (++a)
@mildsunrise if you wrap it in brackets and deref outside doesn't it turn into pre behaviour regardless? (now I'm writing this I'm realising it probably doesn't, but this is c++ so principle of most surprise applies lol)
-
@mildsunrise if you wrap it in brackets and deref outside doesn't it turn into pre behaviour regardless? (now I'm writing this I'm realising it probably doesn't, but this is c++ so principle of most surprise applies lol)
@mildsunrise yeah nah I'm just tiiired
-
@mildsunrise yeah nah I'm just tiiired
@gsuberland dw, relatable
-
i blogged about the memcmp thing
@gsuberland i'm reminded of a weird bug i found in a compiler. in this case the vendor (green hills c compiler for coldfire cpus) converted a sequence like this:
```uint8_t idx;
idx = ;
char newbyte = lookup_table[idx];The code was converting upper/lowercase letters iirc.
In this case the compiler actually converted idx to a signed value using a coldfire MVS.B instruction for some reason, so you could obtain values outside of the lookup table array if the user input a byte >= 0x80.
Not incredibly useful on its own in the app I was analyzing, but the bug was in the compiler itself so needed to be fixed...I never would have spotted the bug were it not for using Ida back in the day.
