Hi Ola, thanks for your response! Ola Lundqvist: > I have now looked into this problem to see if I can out something. > > What I have done is to backtrack whether the code is ever executed by > sqlite and I cannot find that it can be. > > rtreenode function is registered using sqlite3_create_function > in sqlite3_rtree_init. But I cannot find that the sqlite4_rtree_init > function to be called from anywhere. > > Based on this I think we can rather safely say that the function is not > used in Debian and hence the package is not affected. Ok, great. So given that others didn't comment (yet) and we both agree on ignoring CVE-2019-8457 for Jessie LTS, we should do so, at least for now. Let's wait for Security Team's opinion. My recommendation for them would be to do the same, given that backporting the fix for CVE-2019-8457 to the sqlite3 version in Stretch will be as complex as it is for Jessie. > I think we usually > mark it as ignored with a description. An alternative is to mark it as > not-affected but I'm not sure whether that should be done in this case > since the vulnerability is there, just not triggered. Someone else can > maybe help out with that decision. Marking it as 'non-affected' would be wrong as the package *is* affected. It's just that we consider it a minor vulnerability that we ignore for Jessie given that backporting a proper fix would mean very invasive code changes. @Security Team: do you have a suggestion how to mark cases like this one in data/CVE/list? The best probably would be to have a 'no-dla' flag, right? > In addition to that I think we can rather safely mark it as ignored (at > least postponed) since should be seen as a minor issue. Such debug > functions should not be used in live applications and hence the problem is > not that big. SQL permissions in sqlite is not really something you give > access to any user, at least that is my interpretation of its general use. > > I hope this helps a little. It helped a lot, thanks. This leaves CVE-2019-5827 for sqlite3. As written in data/dla-needed, the fix presumably is to migrate to 64-bit memory allocators for integers in order to prevent possible integer overflows. There's been *a lot* of those migrations between Jessie and latest unstable version. If we want to properly fix CVE-2019-5827, we probably have to backport a large portion of them. Cheers jonas
Attachment:
signature.asc
Description: OpenPGP digital signature