3 ms·

Quite interesting the hand waving of security issues with Zig, oh well. If I want to use allocator debuggers I already have the production ready tools that exi

• afdbcreid 4mo ago
  Compilers are not security sensitive, usually. And while UB could theoretically poison the generated code, this isn't a bigger risk than logic bugs.
  • pjmlp 4mo ago
    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.
    • afdbcreid 4mo ago
      Considering that you often run the code after you compile it, it might not matter. Anyway, like it or not, most compilers don't consider themselves security sensitive and will not consider malicious code that is able to hijack the compiler a security vulnerability.
      • pjmlp 4mo ago
        Ken Thompson won the award for nothing, yeah.
        • afdbcreid 4mo ago
          Totally unrelated; The trusting trust attack was about downloading a malicious compiler because malicious code was injected into it in some early version. (And if you ask me, it was indeed overrated, but that's unrelated).
          • pjmlp 4mo ago
            That was one way the attack could be done, there are many other ways if the compiler binary can be open for manipulation.
  • demosthanos 4mo ago
    > 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.
    • uecker 4mo ago
      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 4mo ago
        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 4mo ago
          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).