[aliasEli]

OK, that got down-voted. I thought the basic idea behind HN is that we can have some interesting discussions. Simply down-voting without adding a reply why you disagree with an opinion does not really help.

I have been interested in security for a long time. The number of security vulnerabilities that have been caused by insecure memory management problems is really huge. Some people will probably claim that this is not a problem with modern C++ because it can remedy this problems. But this assumes that the programmers know all the possible pitfalls. With respect to security, the problem is that when there is only a single weakness in your system it might become a point of attack. With a language like C++ there are many possible weaknesses that simply do not exist in memory safe languages.

[csmpltn]

> "Simply down-voting without adding a reply why you disagree with an opinion does not really help."

This looks like a general criticism of using C++ which has nothing to do with the topic of this post. You're free to criticize, but this criticism alone brings absolutely nothing constructive to the conversation and only serves to incite more useless "have you considered writing this in Rust?" conversations. You're not even suggesting what you think they should've used instead.

> "I have been interested in security for a long time"

Here's a tip for you then: security is not an absolute, and things usually aren't as black or white as you might think. Take a moment to consider the fact that C++ is one of only a small handful of languages with which everything around you has been built for the last 30+ years. Do you know something all of those other engineers don't already know? Otherwise, humility goes a long way.

[kevingadd]

The article title literally has 'C++' in it.

[jazzyjackson]

And yet it is more specific.

[flohofwoe]

According to the article, the C++ code is compiled via Emscripten (presumably to WASM, or maybe to asm.js), so it's running sandboxed either in the WASM or JS runtime. Any potential memory corruption caused by unsafe C++ code is contained within the sandbox (which is the whole point of JS and WASM really).

The security implications are exactly the same as writing the code in any other language (incuding Javascript or Rust). If the sandbox is buggy, then a "safe" language wouldn't help either.

[detaro]

Just because the attack is contained inside the sandbox doesn't mean it can't do anything, so no, "it's in a sandbox" does not remove all risk automatically.

[azakai]

You're right that it doesn't remove all risk automatically. You can still corrupt data inside the sandbox.

However, wasm has a very clear sandboxing boundary. The ability of an exploit to escape the sandbox is very small if you are careful there.

IIUC the task here is a user that wants to parse their own files. For that, I think wasm's sandboxing (if used properly) is very useful. Especially since in this case it runs on the web and so we also have the browser's additional isolation (a sandboxed process).

Memory safety is incredibly important, but there isn't a simple answer in the space of tradeoffs, at least not for tasks like this. (For things like running an executable on bare metal that parses arbitrary inputs, obviously things are very different!)

[pjmlp]

A WASM module basically is like an OS process, from security point of view.

So now think what might happen, when not used properly.

Some form of bounds checking should have been part of the design, like memory tagging.

[hoytech]

Yes, exactly, otherwise buggy applications wouldn't be a big deal because we could run them on their own dedicated computers.

Section 2.5 of this paper has a good discussion on this: https://cr.yp.to/qmail/qmailsec-20071101.pdf

[dangerbird2]

In a browser environment, all addressable memory accessible to WASM is more-or-less just a javascript ArrayBuffer object. If you can unintentionally break the browser sandbox with buggy C++ code, someone else has almost certainly already compromised your system with malicious plain ol' javascript.

[mrweasel]

Well, you're not starting of to great by randomly claiming that it's a security issue that it's written in C++. It's not really productive. A lot of software is, for better or worse, written in C or C++, that's not going to change.

For years people have been yelling: "It's broken because it's written in C/C++". That same "attacks" was made to promote Java 20 years ago.

Sure, maybe they could have picked a memory safe language, but they didn't. Perhaps because they know C++ and doing the same project in a language they're just learning would result in a ton of other bugs. They even write that they hired a few brilliant C++ programmers, so chances are that they know how to safely handle memory in C++.

[pjmlp]

From my point of view, better C++ than C, however and not speaking from this project rather in general terms, adopting best practices for secure coding in C++ seems to still be an uphill battle, saying this as C++ aficionado.

https://microblink.com/blog/be-wise-sanitize-keeping-your-c-...

[rfrey]

I disagree with the commenters who are saying your comment was just "C++ bad". The point I took from your comment is that this particular class of application, which is parsing many complex formats from external sources, several of which probably have extensive warts and edge cases, and rendering the output to a browser, is the type of application may be the most vulnerable to the downsides of C++ when it comes to security.

I think it's a reasonable point, and a step or two above "just use Rust".

[aliasEli]

You write better than I do.

[secondcoming]

You're not trying to have a discussion, your post is essentially 'why didn't they use Rust'. Sadly predictable.

There is no-one on HN who doesn't know that C++ has historic memory management difficulties.