bug of the day: a memcmp that only compares every fourth byte
-
@gsuberland is it doing what i think it's doing?
@dysfun it's a constant time implementation if that helps
-
bug of the day: a memcmp that only compares every fourth byte
-
@dysfun it's a constant time implementation if that helps
@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@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)
