daniel:// stenberg://
Hello #MITRE, (regarding CVE-2023-52071)
Well, first I of course think that the "burden of proof" would be on the person that insists that there is a problem. The one saying that this is a #CVE should provide the necessary details to explain "beyond reasonable doubt" that the identified problem is a vulnerability. There are no such details or explanations provided in the existing CVE. There is nothing there that identifies a vulnerability.
daniel:// stenberg://
Let me try:
The claimed issue identifies a bug in curl that
1. only existed in debug-builds (thus disqualified)
2. even in debug-builds, a bad access will at worst cause a crash, which is also what assert itself does when triggered. Thus having the same end result. Not a vulnerability.
3. in most situations, the bad access will not cause any problems at all, even in debug-builds (because the accessed stack memory is readable)
daniel:// stenberg://
My claims can easily be verified and double-checked by simply reading the code. It's not complicated.
/ Daniel
daniel:// stenberg://
I'm convinced someone just grepped commit messages for this and submitted a #CVE and there was nothing and no one that even tried to confirm or check that this was actually legitimate. There was no filter in place and it was incorrectly let through. That's why it should be rejected. Saying it is "disputed" hints that there can be different views on this subject.
So, you are asking me to explain how this not identified vulnerability is actually not identifying a vulnerability.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.