mirror of https://git.code.sf.net/p/isync/isync
Browse Source
if the code was sent in response to anything but a STORE, we'd overwrite a data pointer in one of our imap_cmd subclasses, an allocator data structure, or the start of the next allocation, with an int that was completely under the server's control. it's plausible that this could be exploited for remote code execution. to avoid this, we could ensure that the object is of the right type prior to casting, by using a new flag in the parameter block. but it's easier to just dispose of the out_uid field altogether and reuse the uid field that is present in the parameter block anyway, but was used only for FETCH commands so far. this problem was found by Lukas Braun <koomi@moshbit.net> using a fuzzer.1.3
Oswald Buddenhagen
4 years ago
1 changed files with 14 additions and 5 deletions
Loading…
Reference in new issue