Summary: | games-action/abuse_sdl CAN-2005-0098+CAN-2005-0099 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> | ||||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||
Status: | RESOLVED INVALID | ||||||||
Severity: | minor | CC: | games | ||||||
Priority: | High | ||||||||
Version: | unspecified | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Whiteboard: | B3 [ebuild+] koon | ||||||||
Package list: | Runtime testing required: | --- | |||||||
Attachments: |
|
Description
Sune Kloppenborg Jeppesen (RETIRED)
![]() Created attachment 49739 [details, diff]
/home/jaervosz/patch.CAN-2005-0098.abuse
Created attachment 49740 [details, diff]
/home/jaervosz/patch.CAN-2005-0099.abuse
Later comment on v-s: > - strcpy(level_file,argv[i]); > + strncpy(level_file,argv[i],sizeof(level_file)-1); > + level_file[sizeof(level_file)] = '\0'; This writes the NUL byte just beyond the end of buffer. Other replacements of strcpy() further in the patch have the same problem. Rather than use strncpy(), better use: level_file[0] = '\0'; strncat(level_file, argv[i], sizeof(level_file) - 1); > + setuid(getuid()); > + setgid(getgid()); I don't think it makes a difference here, but it's generally safer to do the setgid() first. And it's a good idea to make sure both calls actually succeed, by checking the return value and aborting on errors. vapier: do we have "abuse" setuid games or root ? This is not setuid or setgid anything on Gentoo. So CAN-2005-0098 is shallow for us since we have nice default protections on to secure ourselves from the weak programming qualities of game coders. That leaves us with the not-really-deep CAN-2005-0099, which can wait for public release and probably isn't worth a GLSA (arbitrary file CREATION + root shouldn't play games). Public with Debian Security Advisory DSA 691-1 Games herd, please apply fix CAN-2005-0099, not sure if fix for -0098 is needed. games team: *bump* Wow... I'm not even sure if our version of abuse is vulnerable... we're currently on 0.7.0, whereas these patches are for 2.0.0, so I need to update abuse along with adding these patches. Alright, I was wrong. The highest version of abuse_sdl is 0.7.0, as we have in portage. abuse_sdl is also all written in C++ and not C, so these patches definitely do not apply. There is an "Abuse2" project, which we do not have in portage. I would suspect that these patches are to that project and not to abuse_sdl. OK then we should consider this one INVALID. If our abuse is vulnerable, its not to the same bug anyway. |