On 19 Jul 2019, at 02:12, Nam Nguyen firstname.lastname@example.org wrote:
I'm working on the impact of CVE-2019-9636 as part of my day-job.
I'd be interesting in your analysis of how you parsing proposal would have avoided this problem before it was described. I add the "before it was described" because I think you are claiming that the universal parser will prevent this class of security issue by the nature of its design.
That's exactly what I'd like the list to consider.
I claim that a parsing library would prevent this class of issues simply because it follows the specification to the letter.
Is the specification complete and unambiguous? Too often there are gaps in a specifications that go unnoticed and lead the problems. Was the specification updated but the code to match it was not?
While a parsing library may, or may not, make an implementation easier to write and review there is still room for human error.
Mistakes in understanding a specification are made by engineers and lead to problems that sometimes take years to discover.
In short I think this may reduce problems, but "prevent" them I do not believe.
As you'll find in my code, the grammar is trivial translation of what is in the spec, one for one. Not only will this help explain what the code is doing, but also raise the confidence that the code matches the spec.
I'm happy to have better tools and making review easier. Of course the parser needs to have a specification, documentation and trusted implementation to get the benefits.
Full disclosure, I fixed bpo30500, but I was not at all confident that the fix was correct. I understood what the code did; I just couldn't tell if that was the right thing to do.
I took at very quick look at bpo30500 and was struck by the comment that the code was working on a URL that had not been validated.
Validation of the URL would reject the URL before the parsing happens in this case. Was that the case?
If the code needs to run with input that is outside the pre-conditions of the specification then you are in a place where you need to not only fix the code, but state that the code extends the spec in non-standard ways.