Closed andymeneely closed 11 years ago
So something does seem fishy here. If I look at server/protocol.c
, with:
select * from timeline where filepath='server/protocol.c' order by attime asc
I see that all of the vulnerabilities all got fixed basically at the same time (numbers increase, then drop off suddenly). That by itself is not a problem, but I'm not sure that's what happened.
For example, I see that CVE-2004-0942 was introduced in 2003 and fixed in 2004, but that doesn't seem to be reflected in the timeline. Here's the manual version of protocol.c's timeline:
SELECT introLog.authorDate intro, fixedRepoLog.authorDate fixed, c2g.*, introLog.*, fixedRepoLog.* FROM cvetogit c2g, repolog introLog, repolog fixedRepoLog WHERE c2g.filepath='server/protocol.c' AND c2g.commitintroduced=introLog.commit AND c2g.commitfixed=fixedRepoLog.commit
Ok, I fixed the SQL query so that it works now. Looking at server/protocol.c and CVE-2004-0942, it works exactly as expected now. And the counts go up and down, as one would expect.
So I went back and checked the query against protocol.c file. Here's the query I executed, and I do seem to get CVE-2004-0942 as a response here if i use some date like jan '06, but if i use jan '03 as date that will not appear as its not fixed yet. Here's the exec
mysql> select distinct cveFixed.cve, repo.commit from CVEToGit as cveFixed, CVEToGit as cveIntro, RepoLog as repo where cveFixed.filepath like '%protocol.c%' and cveIntro.filepath like '%protocol.c%' and repo.filepath like '%protocol.c%' and (cveFixed.CommitIntroduced = repo.commit) and repo.authordate < str_to_date('01/01/2006', '%d/%m/%Y') and cveIntro.cve in (select cve from CVEToGit as cveFixed, RepoLog as repo where cveFixed.commitFixed = repo.commit and (repo.authordate is null or repo.authordate > str_to_date('01/01/2006', '%d/%m/%Y'))); +---------------+------------------------------------------+ | cve | commit | +---------------+------------------------------------------+ | CVE-2010-0434 | 3a3d4cc9ea4c299a0c83f5599f70ca089cccb01f | | CVE-2004-0942 | 9c2f26b85de4db8ae480d0db681aead96ef9a50c | | CVE-2004-0493 | 80858976f26db3c8af5a905601720f2e8f0b8eca | | CVE-2005-2728 | 46a58379a70dee6d146f77e87bd8253eeb108791 | | CVE-2003-0132 | 03a94e64d8fa417ff9862fea1bb423500f743318 | | CVE-2002-0392 | 27677a4383e0c5d63d83a276ab931380976ef925 | | CVE-2011-3192 | e75abb77c7596b93cc01396b740699700b78d213 | | CVE-2011-3368 | cbfc4cad68442bf9a65345981a0e1fceceaf2ec4 | | CVE-2011-3192 | 5430f8800f5fffd57e7421dee0ac9de8ca4f9573 | +---------------+------------------------------------------+ 9 rows in set (11.56 sec)
mysql> select distinct cveFixed.cve, repo.commit from CVEToGit as cveFixed, CVEToGit as cveIntro, RepoLog as repo where cveFixed.filepath like '%protocol.c%' and cveIntro.filepath like '%protocol.c%' and repo.filepath like '%protocol.c%' and (cveFixed.CommitIntroduced = repo.commit) and repo.authordate < str_to_date('01/01/2003', '%d/%m/%Y') and cveIntro.cve in (select cve from CVEToGit as cveFixed, RepoLog as repo where cveFixed.commitFixed = repo.commit and (repo.authordate is null or repo.authordate > str_to_date('01/01/2003', '%d/%m/%Y'))); +---------------+------------------------------------------+ | cve | commit | +---------------+------------------------------------------+ | CVE-2005-2728 | 46a58379a70dee6d146f77e87bd8253eeb108791 | | CVE-2003-0132 | 03a94e64d8fa417ff9862fea1bb423500f743318 | | CVE-2002-0392 | 27677a4383e0c5d63d83a276ab931380976ef925 | | CVE-2011-3192 | e75abb77c7596b93cc01396b740699700b78d213 | | CVE-2011-3368 | cbfc4cad68442bf9a65345981a0e1fceceaf2ec4 | | CVE-2011-3192 | 5430f8800f5fffd57e7421dee0ac9de8ca4f9573 | +---------------+------------------------------------------+ 6 rows in set (6.99 sec)
Looking at the 30-day timeline for server/protocol.c (as of edf4d97930b1291921226137e9653a2d970d98d1), it looks like a whole bunch of vulnerabilities were introduced over time, then fixed all at once. Is that right? Or is that mistake in our query?