[tus666]

> 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.

[CuriousCosmic]

> 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.

[SPBS]

> 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.

[smsm42]

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.

[PedroBatista]

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

[dangets]

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.

[1] http://hintjens.com/blog:106 [2] https://news.ycombinator.com/item?id=39880972

[vasco]

You're that confident in every single line of code you wrote?

[tus666]

No, but I would never, ever, ever, EVER write data to a buffer without specifying the buffer size or reallocing where necessary.

This just smells so much like a Javascript script kiddy who wanted to join the cool brigade and write something h4kor1sh in C. Ugh.

[krainboltgreene]

This comment is like opening the box to a time capsule from 2010. I haven't seen anyone communicate like this since I last touched an IRC channel.

I'm dying at the idea that someone would think C is the "cool brigade".

[sofixa]

Yeah, C hasn't been "cool" in a few decades.

[cjbprime]

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.

[tus666]

Most memory vulnerabilities are use-after-free which due to the nature of C is a very easy mistake to make.

Buffer overflows are simple inexcusable, especially if its "we didn't bother checking" rather than "we got the size wrong due to human error".

The first case is not normal, people like that should not be programming HTML let alone C code.

[cjbprime]

I have some really bad news for you about OpenSSL.