Such is the nature of security vulnerabilities: you look at it and it looks like a really stupid mistake, one that would be really easy to not have made. But the difficulty of writing secure software is not about avoiding any one particular mistake; it's the sheer number of mistakes available to be made, so that it's easy for one mistake to slip through the cracks. To their credit, they seem to have been pretty quick to respond and fix this one (reported on Sep 25, patch live on Oct 1).
A simple adherence to security guidelines for web applications would've prevented it like HTML encoding any values before reflecting them to the client.
So while this is very stupid, this ins't excusable under gosh software is complicated, this is basically XSS in a desktop application.
If this was some RCE through the scanning or sand-boxing engine I would say fine, but this is pretty much the most common web vulnerability out there, I don't understand companies that build HTML based interfaces and decide to simply forgo all of the existing guidelines for web development because it's not a website.
This seems unnecessarily harsh. As you said, XSS is one of the most common vulnerabilities out there - in other words it's a very easy and common mistake to make. I wish we lived in a world where writing an XSS vulnerability was inexcusable incompetence, but the actual world we live in is one where even the best will slip up sometimes and we have to depend on audits, patching and defense in depth. (Which is exactly what happened here; a security researcher audited it, found the problem, and it was promptly patched.)
this ins't excusable under gosh software is complicated,
You're right - this happened precisely because they've made the software more complex than it needs to be. There's literally nothing in a certificate which requires HTML rendering capabilities. Using a plaintext field, the way it would've been done before the "web everything" trend, would not have resulted in this vulnerability.
I have a MITM proxy for filtering too, and testing it with the PoC cert just causes the CN to be displayed as plaintext in the warning message. It does not attempt to interpret it in any other way, as it should be.
> But the difficulty of writing secure software is not about avoiding any one particular mistake; it's the sheer number of mistakes available to be made, so that it's easy for one mistake to slip through the cracks.
I'm not well versed in security, so I can't say anything about this particular mistake; but, as a mathematics teacher, I can say that this is a fantastic description of the perils inherent in any creative activity, not just programming. I hope that I have your permission to steal it for my own future use. :-)
> But the difficulty of writing secure software is not about avoiding any one particular mistake; it's the sheer number of mistakes available to be made, so that it's easy for one mistake to slip through the cracks.
This may be pedantic.. but writing secure software as an individual is not that hard; writing secure software as a team and then publishing that as a product is almost impossible.
Please do not use the titles of HN submissions to editorialize. (Submitted title was "Avast Antivirus: X.509 Error Rendering Command Execution (patched but shocking)".)
Copy. I sat thinking about the title for a bit. I primarily wanted to point out that I did not miss the fact that it had been corrected--merely that it is a surprising vulnerability.
12 comments
[ 3.1 ms ] story [ 35.2 ms ] threadSo while this is very stupid, this ins't excusable under gosh software is complicated, this is basically XSS in a desktop application.
If this was some RCE through the scanning or sand-boxing engine I would say fine, but this is pretty much the most common web vulnerability out there, I don't understand companies that build HTML based interfaces and decide to simply forgo all of the existing guidelines for web development because it's not a website.
You're right - this happened precisely because they've made the software more complex than it needs to be. There's literally nothing in a certificate which requires HTML rendering capabilities. Using a plaintext field, the way it would've been done before the "web everything" trend, would not have resulted in this vulnerability.
I have a MITM proxy for filtering too, and testing it with the PoC cert just causes the CN to be displayed as plaintext in the warning message. It does not attempt to interpret it in any other way, as it should be.
I'm not well versed in security, so I can't say anything about this particular mistake; but, as a mathematics teacher, I can say that this is a fantastic description of the perils inherent in any creative activity, not just programming. I hope that I have your permission to steal it for my own future use. :-)
This may be pedantic.. but writing secure software as an individual is not that hard; writing secure software as a team and then publishing that as a product is almost impossible.
The reason that's better is that then your comment is on a level field with everyone else's.