Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: TheAssassin <theassassin_at_assassinate-you.net>
Date: Thu, 19 May 2022 12:23:03 +0200
> Anything other than the standard OS-specific bundle is going to look magic to
> the user. For example, if the path were set to
> /etc/motd:/etc/pki/tls/certs/ca-bundle.crt then a file created at
> /etc/motd would magically (i.e. unexpectedly) cause TLS connections to
> stop working.
I don't see why a user would add that path. If a user would compile
libcurl with /etc/motd as the main CA certificate bundle path at the
moment, unexpected behavior will occur as well. It is the job of the
developer who generates the libcurl binary to provide proper paths.
> Yes, that's a contrived worst-case example, and if AppImage
> points it to an internal sandboxed path and documents it appropriately it
> shouldn't be a problem.
AppImages are not sandboxed. Think of them as a slightly more advanced
alternative to a self-extracting archive (the "extract" process is
replaced by mounting the payload using FUSE). Also, I mentioned
previously that I'd prefer not to ship a CA certificate bundle within
the application bundle but use the system bundle.
> The most straightforward example is if the path included a world-writable
> location, then an attacker could place a bad certificate there and enable a
> MITM attack. Since there currently is no search within libcurl, there is
> currently no danger.
Whether you support one bundle or multiple bundles doesn't make a big
difference. The proposed paths are all in read-only, root-writable
locations, as per the FHS. Only distributions which ignore this standard
could maybe be affected by such an issue. But then again, the existing
single CA bundle path may be writable as well.
But then again you need to take into consideration that AppImages (or
tarballs or any other relocatable bundle) are owned by the user who
executes them. There is no security gain if a libcurl contained inside
such a bundle would just check a single location, since an attacker
could just replace that libcurl and rebuild the bundle. This feature
doesn't open a new attack vector that is worse than that (which requires
access to the host computer first anyway).
Received on 2022-05-19
Date: Thu, 19 May 2022 12:23:03 +0200
> Anything other than the standard OS-specific bundle is going to look magic to
> the user. For example, if the path were set to
> /etc/motd:/etc/pki/tls/certs/ca-bundle.crt then a file created at
> /etc/motd would magically (i.e. unexpectedly) cause TLS connections to
> stop working.
I don't see why a user would add that path. If a user would compile
libcurl with /etc/motd as the main CA certificate bundle path at the
moment, unexpected behavior will occur as well. It is the job of the
developer who generates the libcurl binary to provide proper paths.
> Yes, that's a contrived worst-case example, and if AppImage
> points it to an internal sandboxed path and documents it appropriately it
> shouldn't be a problem.
AppImages are not sandboxed. Think of them as a slightly more advanced
alternative to a self-extracting archive (the "extract" process is
replaced by mounting the payload using FUSE). Also, I mentioned
previously that I'd prefer not to ship a CA certificate bundle within
the application bundle but use the system bundle.
> The most straightforward example is if the path included a world-writable
> location, then an attacker could place a bad certificate there and enable a
> MITM attack. Since there currently is no search within libcurl, there is
> currently no danger.
Whether you support one bundle or multiple bundles doesn't make a big
difference. The proposed paths are all in read-only, root-writable
locations, as per the FHS. Only distributions which ignore this standard
could maybe be affected by such an issue. But then again, the existing
single CA bundle path may be writable as well.
But then again you need to take into consideration that AppImages (or
tarballs or any other relocatable bundle) are owned by the user who
executes them. There is no security gain if a libcurl contained inside
such a bundle would just check a single location, since an attacker
could just replace that libcurl and rebuild the bundle. This feature
doesn't open a new attack vector that is worse than that (which requires
access to the host computer first anyway).
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature