> By reading the source code, I realized that the incoming data was put into a fixed-size static buffer in the stack, and the payload was decrypted into another fixed-size buffer. There’s no boundary or size check.
This is not normal. It's amateurish in the extreme that leads to the only conclusion that whoever wrote this ZeroMQ thing is not a real software engineer. I.e. stay away at all costs.
> This is not normal. It's amateurish in the extreme that leads to the only conclusion that whoever wrote this ZeroMQ thing is not a real software engineer. I.e. stay away at all costs.
I don't think that's a remotely fair assessment. ZeroMQ is a very large and quite popular project but it's also getting close to two decades old if I remember correctly. Any large C or C++ project that is that old is going to have quite a bit of historical cruft. And looking at some of the code that said vulnerability touched, most of that code was over a decade old.
Not to claim that it's any less severe but this is the nature of long lived projects. Unless they are massively privileged, they tend to have more code than eyes to look at said code and said code often was written in the bad old days.
> it's also getting close to two decades old if I remember correctly. Any large C or C++ project that is that old is going to have quite a bit of historical cruft.
I don't think writing arbitrary data into fixed-size buffer without boundary checks is just an artifact of being historical cruft, it's a ridiculous mistake no matter which time period it was written in. Whoever wrote that code decades ago was incredibly amateurish.
That assuming the code was written that way initially. More often than not in long running projects pieces get moved around, refactored, functionality added and removed, and silent assumptions that were true before aren't true anymore. Somebody coded functionality for fixed data buffer, somebody else extended it with variable sized data but was not aware fixed buffers are being used, that stuff happens. We live in a myriad of glass castles, don't be so quick to throw stones around.
The tone of some comments like this one makes me wonder if the authors ever wrote any software of reasonable complexity, on their free time while getting paid zero dollars.
With such high standards I wonder why this people use such amateur software and not make or buy their own professional grade software.
Also sheds light why truly free open source software is such a thankless and hazardous activity
Pieter Hintjens who started ZeroMQ, advocated for 'optimistic merging' as a strategy to encourage community & project building [1] (prev discussed in [2]). For all of the benefits listed it does open it up to lower quality or malicious merges.
Literally every serious C/C++ project has shipped memory unsafety vulnerabilities. We have discovered, as the global community of programmers, that humans are not smart enough to write C code without doing that. It is time to blame the language (or the species) and move on.
Let's not pretend that the people writing the unsafe code are unimaginably stupid. They are extremely imaginably stupid, as we all are.
This is not normal. It's amateurish in the extreme that leads to the only conclusion that whoever wrote this ZeroMQ thing is not a real software engineer. I.e. stay away at all costs.