[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
> This would be a bit of additional work, but security and confidence > are usually at the opposite ends of the same scale. s/confidence/convenience/ I knew what I meant, of course. -- Denis Ovsienko ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
On Tue, 2 Apr 2024 14:06:28 +0200 Francois-Xavier Le Bail via tcpdump-workers wrote: > Even if we keep the tarball archive, we could have a host compromise > (bad autoconf, etc.) and if the "configure" script is generated on > it, we risk to open a door to an attack. > > Thus, don't deliver "configure" in the tarball and ask to run > "./autogen.sh" with autotools installed. Let's consider the problem and the solution. If the host is fully compromised (a remote attacker made themselves the root user of my computer's OS), there is little point in trying to game around it. I delete configure, they put the virus into autogen.sh. I delete autogen.sh, they put the virus into mkdep. I delete mkdep, they put the virus into Makefile.in. I delete Makefile.in, they put the virus into CMakeLists.txt. I delete CMakeLists.txt, they put their own file of any name and contents into the tarball because they are not limited by the contents of the git repository. They just need me to sign and publish a tarball with their contents. If the host is mostly clean, but the Autoconf package is compromised through the upstream or otherwise, it means the compromised Autoconf package is not limited to placing the virus into configure. It may happily produce a correct clean configure from a correct clean configure.ac, and then add the virus into configure.ac or autogen.sh or mkdep or Makefile.in or... If the host is clean and Autoconf is clean and every other package is clean, but the developer is compromised, then in that case why the compromised developer would limit themselves to the configure script if they have full control of the release archive contents and the git repository contents? What would prevent a compromised developer from publishing a "secure, configure-free" tarball with a virus in some other file (configure.ac, etc.)? If the host is clean and all packages are clean and the developer is clean and the tarball has no configure script, then the users that want to compile the source will need to supply their own Autoconf, which can be compromised as realistically as yours or mine, so effectively excluding the configure script does not solve the problem, but shifts it to somebody else's side of the fence and multiplies the number of times it will need to be solved after the release. It would not be impossible for every user that builds from source to arrange a compatible version of Autoconf (you have to build it first in pkgsrc, for example, and the dependencies) and to verify that their Autoconf is not compromised. Some users take exactly this approach and run "autoreconf -f" as the very first step no matter if the tarball included configure or not. Other users choose not to duplicate the work unnecessarily, but to trust the software developers to figure the details out correctly once and to use a clean release environment correctly once, and to publish a tarball that is not compromised, has a ready to run configure script and a signature. This is a reasonable expectation. A possible way to add confidence to the process could be additional verification. Individual computers and OSes can be compromised. To that end, for example, the release maker could run "make releasetar" on at least two separate physical computers, each with a different OS and a different architecture, and let a script compare the results. Computers are small and very affordable now. Individual developers can be compromised. When one developer produces the signed tarballs at their end, another could run "make releasetar" at their end and let a script compare the contents and verify the signatures. This would be a bit of additional work, but security and confidence are usually at the opposite ends of the same scale. -- Denis Ovsienko ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
--- Begin Message ---
On 01/04/2024 20:18, Guy Harris wrote:
> On Apr 1, 2024, at 6:53 AM, Michael Richardson wrote:
>
>> I wonder if we should nuke our own make tarball system.
>
> I.e., replace:
>
> to get {libpcap,tcpdump,tcpslice} version X.Y.Z, download
> {libpcap,tcpdump,tcpslice}-X.Y.Z.tar.{compression-suffix}
>
> with
>
> to get {libpcap,tcpdump,tcpslice} version X.Y.Z, do
>
> git clone {repository}
>
> and then check out Git tag {libpcap,tcpdump,tcpslice}-X.Y.Z?
>
> If so, do we
>
> 1) require people to have autotools installed and run ./autogen.sh
>
> or
>
> 2) generate the configure scripts on some standard platform and check
> it in
>
> so that they have a configure script? Or is there some other way to arrange
> that people can get the configure scripts?
Even if we keep the tarball archive, we could have a host compromise (bad
autoconf, etc.) and if the "configure" script is generated on it, we risk to
open a door to an attack.
Thus, don't deliver "configure" in the tarball and ask to run "./autogen.sh"
with autotools installed.
--- End Message ---
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
On Mon, 01 Apr 2024 09:53:38 -0400 Michael Richardson wrote: > The entire openwrt thread is at: > https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042499.html > continuing at: > https://lists.openwrt.org/pipermail/openwrt-devel/2024-April/042521.html > > > Daniel Golle wrote: > > However, after reading up about the details of this backdoored > > release tarball, I believe that the current tendency to use > > tarballs rather than (reproducible!) git checkouts is also > > problematic to begin with. > > > Stuff like 'make dist' seems like a weird relic nowadays, > > creates more problems than it could potentially solve, > > bandwidth is ubiquitous, and we already got our own tarball > > mirror of git checkouts done by the buildbots (see > > PKG_MIRROR_HASH). So why not **always** use that instead of > > potentially shady and hard to verify tarballs? > I wonder if we should nuke our own make tarball system. The short answer is "no". Before I go into detail, please try not to take the following comments personally, but to focus on the problem. The problem seems to be a bit bigger than this project, so this in part preemptively addresses arguments you did not make, but other people did in other similar arguments about the same matter. First of all, the root cause is not a technical problem: a widely used software project got compromised, on this occasion a developer was the attack vector. Some people feel more angry or scared about it than usual (this is neither the first nor the last nor the biggest incident of this kind, truth be told) and I sympathise with these temporary emotions. However, I do not sympathise with the widespread urge to demonstrate control over the situation by any means or to vent the frustration right now at... something... anything really, does not matter, whatever happens to be in plain sight right now. Likewise, the proposed move would not be a technical solution, or a solution at all. It would scratch a momentary emotional itch today with no regard to the technical lessons learned yesterday and technical problems to be solved tomorrow. Let's try to apply a bit of critical thinking to the matter: * Speaking of Autoconf imperfections, please note that CMake has been available for several years. That said, CMake project definitions are not immune to being used as a delivery vehicle for an exploit into an open source project. CMake executables are not immune to being compromised. make (whether GNU or not) is not immune. The compiler is not immune. The linker is not immune. The libc is not immune. The OS is not immune. And (now we are getting to the difficult part) neither hardware nor VM hypervisors are immune to being compromised. Let's leave Autoconf in peace, it is not the root cause. * Speaking of imperfections of published signed tarballs, please note that the public git repositories have been available for many years. That said, a git repository is not immune to being used as a delivery vehicle for an exploit into an open source project. Just labelling something with "stored securely in git" does not automatically eliminate the threat. For the avoidance of doubt, git as a piece of software is not immune to being compromised. And online services that host git repositories are not immune either. Considering the problem of getting the source code by some means, the only way to guarantee having the exact actual source code is actually to have the exact actual source code. Which in git parlance means actually having a local git clone that (possibly among many other things) includes the very specific revision of interest, which overshoots the problem space massively. If you look at kernel.org and compare downloading of a tarball of a specific kernel version to cloning a repository (which? how deep?) and identifying the correct tag, the difference should be obvious. These two solutions address two different problems, neither is the root cause and neither is immune to being compromised. To demonstrate the difference between the two solution spaces further, git repositories by design do not store file modification times or permissions other than the executable bit, so in practice two identical, as far as git is concerned, clones tend to be different, as far as "ls -lR" is concerned. Let's leave signed tarballs in peace. There is a valid concern of whether a tarball is a close enough result of "make releasetar" for the respective git tag. Let's not guess, let's prove it. Would anybody like to implement a script that would compare the contents of https://www.tcpdump.org/release/ with the git repositories? * The "all git repositories are already available" argument does not hold, for example, when one starts with a fresh install of NetBSD with just make, cc and a tarball of pkgsrc release. Before you can use git,
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
On Mon, Apr 1, 2024 at 11:06 AM Michael Richardson wrote: > > Bill Fenner wrote: > > mcr suggested: > >> I wonder if we should nuke our own make tarball system. > > > The creation of a tarball and its signature gives a place to hang > one's hat > > about origin of code - "someone with the right key claims that this > tarball > > genuinely reflects what the project wants to distribute". Is there a > > similar mechanism for a git tag? > > Yes, git tag -s, lets you sign a commit with a PGP key. > Just trying to brainstorm about how this fits with build systems like Arista's, where we store the tarball and check the signature at build time - I suppose it just turns into "vendor the git tag into a local repo and check the signature at build time". I have no objection to either requiring people to have autotools, or going cmake-only. (I mean, I personally find cmake hard to use, but that shouldn't influence what the project does.) Bill ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
Guy Harris wrote: > If so, do we > 1) require people to have autotools installed and run ./autogen.sh > or > 2) generate the configure scripts on some standard platform and check it in 3) stop using autoconf, cmake only. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
--- Begin Message ---
On 01/04/2024 20:18, Guy Harris wrote:
> On Apr 1, 2024, at 6:53 AM, Michael Richardson wrote:
>
>> I wonder if we should nuke our own make tarball system.
>
> I.e., replace:
>
> to get {libpcap,tcpdump,tcpslice} version X.Y.Z, download
> {libpcap,tcpdump,tcpslice}-X.Y.Z.tar.{compression-suffix}
>
> with
>
> to get {libpcap,tcpdump,tcpslice} version X.Y.Z, do
>
> git clone {repository}
>
> and then check out Git tag {libpcap,tcpdump,tcpslice}-X.Y.Z?
>
> If so, do we
>
> 1) require people to have autotools installed and run ./autogen.sh
I vote for 1).
--- End Message ---
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
On Apr 1, 2024, at 6:53 AM, Michael Richardson wrote:
> I wonder if we should nuke our own make tarball system.
I.e., replace:
to get {libpcap,tcpdump,tcpslice} version X.Y.Z, download
{libpcap,tcpdump,tcpslice}-X.Y.Z.tar.{compression-suffix}
with
to get {libpcap,tcpdump,tcpslice} version X.Y.Z, do
git clone {repository}
and then check out Git tag {libpcap,tcpdump,tcpslice}-X.Y.Z?
If so, do we
1) require people to have autotools installed and run ./autogen.sh
or
2) generate the configure scripts on some standard platform and check
it in
so that they have a configure script? Or is there some other way to arrange
that people can get the configure scripts?
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
Bill Fenner wrote: > mcr suggested: >> I wonder if we should nuke our own make tarball system. > The creation of a tarball and its signature gives a place to hang one's hat > about origin of code - "someone with the right key claims that this tarball > genuinely reflects what the project wants to distribute". Is there a > similar mechanism for a git tag? Yes, git tag -s, lets you sign a commit with a PGP key. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
mcr suggested: > I wonder if we should nuke our own make tarball system. The creation of a tarball and its signature gives a place to hang one's hat about origin of code - "someone with the right key claims that this tarball genuinely reflects what the project wants to distribute". Is there a similar mechanism for a git tag? Bill ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
