1. 33
  1.  

  2. 11

    In what scenario does one run pkgconf on untrusted .pc files? I’m trying to understand why the billion laughs thing is treated as a serious vulnerability.

    1. 4

      It’s not likely to happen in a distributed .pc file, but we can all agree that it would be nice for there to be no vulnerabilities at all, even if they’re unlikely to happen.

      1. 1

        CI when testing a change for example. But also, apart from the one you wrote, what .pc file is ever trusted?

        1. 7

          A .pc file is a set of instructions describing arbitrary code that you will inject into your build. It tells you the header files to include and the flags to pass to the compiler, both of which may contain macros that redefine any symbol in your program to do different things. It then tells you the libraries to link, directly injecting code from the person who wrote the .pc file into your binary. If a malicious person can tamper with the .pc file then they have much better ways of attacking your build pipeline than attacking pkgconf.

          The only situation in which that attack vector would make sense is if your program runs with (externally enforced) reduced privileges but your build process does not. Modern CI systems run in isolated environments and so compromising the CI environment is useful only if it allows you to inject bad code into the final binary.

          1. 1

            I’m general, you’re right, but i wouldn’t discount it as an issue. Sometimes the big problems consist of a chain of harmless, weird behaviour. And sometimes you don’t control the whole environment, but only (for example) a prefix to some specific path that just happens to match a pkg-config.

            I agree it’s extremely unlikely to affect anyone, but there may well be some weird scenario where this is exactly what you need to DoS someone’s build pipeline in a very indirect way.

          2. 4

            Your whole CI build should be untrusted though, at least for external contributors.

        2. 6

          I understand the frustration that must be evoked when someone dumps on your project, and the author has given a pretty measured response in my view. I would have found the throwaway “they should run asan” pretty galling.

          However:

          Notably, he submitted a patch, which amongst other things, claims that pkgconf does not consider /usr/include to be a system include path.

          No, it doesn’t claim that. It claims that pkgconf does not filter “-I /usr/include” (note the space) from the cflags. This claim is verifiably true; “-I/usr/include” gets filtered, but the semantically equivalent “-I /usr/include” doesn’t.