Hi, we have an organization requirement to run Fortify against all the code of our service including 3rd party software (our service uses Redis 3.2.12).

Fortify reports a number of issues mainly around Buffer overflow, many of them i'm able to resolve as false positives but there is a remaining list that gets pretty deep in the Redis code where i'm not able to easily identify if a real issue or not.

Here is a list;
1. Buffer Overflow /src/dict.c : 268 SCA High 2. Buffer Overflow /src/dict.c : 273 SCA High 3. Buffer Overflow /src/dict.c : 366 SCA High 4. Buffer Overflow /deps/lua/src/ lstring.c : 62 SCA Critical 5. Buffer Overflow /src/lzf_c.c : 236 SCA High 6. Buffer Overflow /src/lzf_c.c : 236 SCA High 7. Buffer Overflow /src/lzf_c.c : 236 SCA High 8. Buffer Overflow /src/lzf_c.c : 241 SCA High 9. Buffer Overflow /src/lzf_c.c : 241 SCA High 10. Buffer Overflow /src/lzf_c.c : 241 SCA High 11. Buffer Overflow /src/lzf_c.c : 266 SCA High 12. Buffer Overflow /src/lzf_c.c : 281 SCA High 13. Buffer Overflow /src/lzf_d.c : 153 SCA Critical 14. Buffer Overflow /deps/jemalloc/src/prof.c : 1414 SCA Critical 15. Buffer Overflow /src/sds.c : 263 SCA Critical 16. Buffer Overflow /src/t_zset.c : 646 SCA Critical 17. Buffer Overflow /src/t_zset.c : 647 SCA High 18. Buffer Overflow /src/ziplist.c : 440 SCA High 19. Buffer Overflow /src/ziplist.c : 503 SCA Critical 20. Buffer Overflow /src/ziplist.c : 639 SCA Critical

Could a Redis developer take a look and identify if these are false or real issues (and if real a way to mitigate them)? Thanks.

Comment From: tiwatso

If helpful i could provide the fortify trace analysis for the above issues. For instance here is one for dict.c (line 268);

screen shot 2019-01-10 at 1 53 59 pm

screen shot 2019-01-10 at 1 54 13 pm

Comment From: danielelkabes

Any updates regarding this issue ? @tiwatso

Comment From: oranagra

looking at the report for dict.c, it seems like a false positive, unless fortify knows something that i'm missing and isn't specifying it (in this screenshot). it looks like it complains that d->ht[1].table[h] would overflow (h being outside of table). i wonder why it doesn't report that on the line above it. anyway, h is &ded with sizemask which is the mask computed for the size of table. so either fortify isn't smart enough to track this fact (what sizemask means), which seems reasonable. or it's smart enough to know that and figured out some edge case which i don't see reported.

i'm closing this issue, please re-open if you have more info that contradicts that.