CVE issue tracking

[quickfur]

Just wondering if it's possible to keep track of the list of vulnerabilities in Botan as they apply to this D port? E.g., a list of CVE numbers? I see that the current Botan version is listed as 1.11.10, which at least in the C++ version seems to be vulnerable to CVE-2017-14737, CVE-2016-9132, CVE-2016-6879, CVE-2016-6878, CVE-2016-2850, CVE-2016-2849, CVE-2016-2196, CVE-2016-2195, CVE-2016-2194, ... and a bunch of others. But I don't know how many of these apply to the D port, since presumably some of the buffer overflows ought to be prevented by bounds checking in D, and perhaps some of the other issues may also be prevented by other D features.

I guess the point is, is there some way to track which issue(s) affect this D port of Botan? Because it's not clear, at a glance, what vulnerabilities may exist.

[etcimon]

You guessed right, a lot of vulnerabilities to the original Botan cannot apply here because the containers and memory management is completely different, built on the safe programming paradigms of D. The original library has branched off a little too much as well. There has been some progress on "preventative" constant-time algorithms that I'm trying to find time to implement, so this might be something to keep an eye on. On the other hand, as someone who has done some security research against software, the CVEs are also somewhat a dictionary of attacks that you can use against outdated versions, and I think one of the perks of using Botan D is the absence of such research against it which makes the exploits of it that much more difficult to pull off.

As with any library, there's certainly going to be vulnerabilities so if you find one send me a private message and we'll get it patched.

[quickfur]

It's good to know the D port at least avoids certain common vulnerabilities often found in C/C++ code. :-P

OTOH, I would feel a little safer if there was actually an independent 3rd party researching vulnerabilities against the D version specifically. Absence of research doesn't imply absence of bugs, unfortunately, and since this is a public repo, there is no guarantee a black hat has done research against it but hasn't reported the problem (e.g., saving it to exploit for himself, or more likely, add it to a collection of sellable exploits on the black market). Very unlikely, of course, since there is not much audience for D-specific exploits, but still, it would help ease my mind if there was stronger assurance about the absence of bugs.

[etcimon]

Yes, in that case I would advise against using it in important public applications if you feel there is too much to lose. I personally don't trust any popular security library because of the high odds that most vulnerabilities discovered by black hat researchers / cyber warfare will be part of an always-expanding "unknown" arsenal. The worst case scenario to me is the leak of private key due to a buffer overflow / arbitrary range, and I've made this library so that I could at least have some personal assurance that I'm safe on that end.