Hi Ola, The renderdoc situation certainly seems out of the norm for what we see.
On Fri, Jun 16, 2023 at 11:34:25PM +0200, Ola Lundqvist wrote: > Hi > > I'm triaging the package "renderdoc" and it has three open CVEs. More > information about the CVEs are available here with a good description. > https://www.openwall.com/lists/oss-security/2023/06/06/3 > > One of them is clearly a minor issue, but two of them describe the > possibility to execute arbitrate code for a remote attacker as the > user running the software. So that is rather severe. It is only during > the time the person in question run this software and since it is a > debugger it is likely not that common. > Based on the description in that post, the exploitation is rather complex. However, it appears that there is no way for the user to configure the software to stop the bad behavior, so the options for a workaround are very limited to non-existent. > >From the popularity statistics it does not look to be very popular. > > When looking through the patches they will definitely not apply to the > version in buster. To fix the problems at hand someone need to look > through the code with the spirit of the one fixing this and do similar > changes. The code has changed significantly so this is a non-trivial > task. Doable, but will probably take quite some time and effort. > I took a quick look at just one of the relevant upstream commits (in comparison to what is in bullseye) and I agree that a backport is essentially out of the question. Going back even further to buster would be even more difficult. It doesn't help that upstream continues the 1.x branch to be one continuous line of development. So, it seems likely that upstream would have any interest in helping backport the fixes that far into the past. That said, I also looked at the rdeps for all of the binary packages produced by src:renderdoc and it seems like there are no rdeps from other source packages. To my mind, that opens the door to synchronize buster (and presumably bullseye) with a newer upstream release. Looking at the build-depends of renderdoc in sid/trixie/bookworm, it appears that a direct backport to buster will require a bit of work (either to make it work an older gslang, or to backport a newer gslang to buster, though I did not look to see what the potential ramifications of that are). > My conclusion is that the severity is likely high (if the problem > description is correct) if someone can exploit the issues. But the > cost of fixing is quite high, and the likelihood of someone actually > using this software is very low. I mean someone need to use this > debugger on a completely unprotected machine (n public network) where > someone happen to scan for this specific port that only this software > happen to use. It is public information that this vulnerability exists > but since hardly anyone use it I guess such scanners are rare, if even > existing. > > So what do you think? Should I add this package to dla-needed, or what > do you other think? > My opinion is that the package should be added to dla-needed.txt with a note linking to this thread on the mailing list. > If we only follow the regular rules, we should add it do dla-needed, > but should we also the cost aspect for such a rarely used software > component? > > It has not been triaged for bullseye yet. > There should also be a note there to consider backporting a new upstream release once the security team decides what to do for bookworm and bullseye. It may be that the security team decides to bring the latest upstream (1.27) into sid/trixie/bookworm/bullseye, or that they elect to backport the relevant fixes to the version in bookworm (1.24). We wouldn't want to jump on 1.27 for buster only to end up with a higher version in buster than in bullseye. It might be good for whoever claims renderdoc in dla-needed.txt to make an attempt at backporting the commits to 1.24 and then reach out to the security team with assessment (e.g., "yes, backporting is probably going to work" or "no, that doesn't seem feasible and the latest upstream release might be the only viable route") and then perhaps offer to assist with the work. Regards, -Roberto -- Roberto C. Sánchez
