Compilers are not security sensitive, usually. And while UB could theoretically poison the generated code, this isn't a bigger risk than logic bugs.

▲

demosthanos 5 hours ago | parent | next [-]

> Compilers are not security sensitive, usually.

The compiler is one of the most significant trust boundaries we have. Its decisions can intentionally or unintentionally create vulnerabilities in programs compiled by the compiler, which means that if you can compromise a compiler you can compromise everything downstream.

Unsafe memory access in a compiler can be exploited in order to hijack the compiler itself (this is reported regularly in production compilers), allowing the attacker to then insert arbitrary code into compiled binaries. Not everything that a compiler absorbs from its environment is meant to be treated as source to be compiled, and in a memory unsafe compiler any of that input can silently turn into machine code in the compiled binary if an attacker is able to exploit the memory safety bug and hijack the compiler.

▲

afdbcreid 42 minutes ago | parent | next [-]

Most compilers do not consider themselves a security boundary, and will not try to limit malicious code from hijacking the compiler. E.g. LLVM is explicitly not designed to handled malicious code (https://llvm.org/docs/Security.html#what-is-considered-a-sec...).

▲

uecker 3 hours ago | parent | prev [-]

For this to be useful you would need to modify the compiler binary to make the exploit persistent. Otherwise why put an exploit for the compiler in the source to so that the compiler can put some malware in a binary, when you can put the malware in the source directly?

▲

demosthanos 2 hours ago | parent [-]

Because:

1. There are lots of things that compilers load into their memory that aren't actually source code. A memory exploit turns non-source data into executing-in-the-compiler code.

2. Depending on the language semantics, a memory exploit can allow substantially higher privilege than just being loaded as library code. Latent malicious code that never gets called into never becomes active, but if you can exploit a weakness in the compiler you can make your code execute at any time you'd like instead of relying on the main application calling in to your malicious library.

	▲	uecker 2 hours ago \| parent [-]
		1. What would this be? 2. Good point, but for most purposes I think exploiting some aspect of the build system or the language that moves the exploit code or causes it to be executed before main would be easier than exploiting a memory issue in the compiler (I agree though in principle).

▲

pjmlp 5 hours ago | parent | prev [-]

Of course they are, anything can be a gateway to inject backdoors, if security is not taken into account.

And as mentioned, if what Zig offers is already in Purify, there is hardly any added value over C and C++, without the headaches of a niche language.