subject:"Three steps we could take to make supply chain attacks a bit harder"


On 2024-03-30 11:52, Dmitry Belyavskiy wrote:


We have an upstream-adjusted version of this patch, see 
https://bugzilla.mindrot.org/show_bug.cgi?id=2641
I'm OK to bring the updated version of this script to Fedora as soon 
as it is finalized.



I proposed https://src.fedoraproject.org/rpms/openssh/pull-request/72 , 
which uses the implementation from 
https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

Richard W.M. Jones wrote:
> Yes, in this case the attacker had set the serial number to 30, but
> the latest upstream serial number was 3.  autoreconf won't replace the
> file in this case unless it is deleted.  There really should be an
> "always replace if you can" option in autoreconf.

Is that not what -f is supposed to do? At least, the documentation claims 
so, but the implementation does not actually do what is documented.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]

Gary Buhrmaster wrote:
> And, more importantly, the industry has agreed
> to use the term supply chain.  Is the term
> perhaps overloaded, or perhaps too
> ill-defined/imprecise?  Sure.  But if one wants
> to use a different term one would need to work
> across the industry to change the term, and
> that is not going to happen.

Well, one could argue that Free Software is a community, not an industry, so 
"the industry" cannot agree on anything, and "supply chain" as an industrial 
term obviously does not apply. And also that it is called "Free Software" 
and not "Open Source". :-)

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Adam Williamson

On Wed, 2024-04-03 at 00:15 +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > It occurs to me - maybe you don't agree, but this is how it looks to me
> > - that, ironically, you and I usually argue the exact *opposite* side
> > of this case, no? I argue in *favor* of somewhat-arbitrary delays to
> > packages appearing in 'stable', and you argue *against* them. :D
> 
> I have never argued against updates-testing existing or that all packages 
> should skip updates-testing. "Please pick up this new upstream version, it 
> has some great new features" as was done here is exactly the kind of changes 
> that SHOULD go through updates-testing. But if the maintainer has something 
> urgent to push out, such as an important regression fix or a critical 
> security fix (e.g., a fix for a backdoor like this one), they should be 
> allowed to decide to skip testing and not be treated as being too 
> incompetent for that (while at the same time allowing any other person, with 
> no other credentials than a FAS account, to +1 the package, allowing it to 
> be autopushed to stable – everyone except the one person most qualified to 
> make that decision). THAT is what I have been arguing for all this time, and 
> I do not see how this contradicts my position here in any way.

Fair enough. I think the rest of my post stands, though, as it was more
about my argument than yours.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

Adam Williamson wrote:
> It occurs to me - maybe you don't agree, but this is how it looks to me
> - that, ironically, you and I usually argue the exact *opposite* side
> of this case, no? I argue in *favor* of somewhat-arbitrary delays to
> packages appearing in 'stable', and you argue *against* them. :D

I have never argued against updates-testing existing or that all packages 
should skip updates-testing. "Please pick up this new upstream version, it 
has some great new features" as was done here is exactly the kind of changes 
that SHOULD go through updates-testing. But if the maintainer has something 
urgent to push out, such as an important regression fix or a critical 
security fix (e.g., a fix for a backdoor like this one), they should be 
allowed to decide to skip testing and not be treated as being too 
incompetent for that (while at the same time allowing any other person, with 
no other credentials than a FAS account, to +1 the package, allowing it to 
be autopushed to stable – everyone except the one person most qualified to 
make that decision). THAT is what I have been arguing for all this time, and 
I do not see how this contradicts my position here in any way.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

Gordon Messmer wrote:
> Purely as trivia, and as I haven't seen it discussed elsewhere, the
> malware steals a different set of symbols on Fedora, where
> RSA_public_decrypt doesn't seem to appear in the GOT at all.

This proves again that this is a very targeted attack that carefully 
analyzed the individual targeted distributions, the distributions whose 
packaging tools the build script attempts to detect were not just picked 
because they are known to link OpenSSH to liblzma, but also individually 
tested and targeted.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Stephen Gallagher

On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette  wrote:
>
> I personally would very much agree with enforcing the use of 2fa on the 
> Fedora Account System. Maybe take that opportunity to make it a bit more user 
> friendly? (Such as the fkinit prompt requiring the 2fa code being added at 
> the end of your password -- to be clear I think the 2fa code should be 
> separate)

https://pagure.io/fedora-packager/pull-request/179
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Steve Cossette

I personally would very much agree with enforcing the use of 2fa on the
Fedora Account System. Maybe take that opportunity to make it a bit more
user friendly? (Such as the fkinit prompt requiring the 2fa code being
added at the end of your password -- to be clear I think the 2fa code
should be separate)

On Tue, Apr 2, 2024 at 3:06 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Chris Adams wrote:
> > However, it's a good trigger to review Fedora's security approach in
> > general (like 2FA use).
>
> Using such an issue that made it through upstream 2FA and would also have
> made it through any 2FA enforcement in Fedora as an excuse to force 2FA on
> us is just pure nonsense.
>
> Kevin Kofler
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder


On 2024-04-02 03:42, Lennart Poettering wrote:

Also, I don't think we should get hung up too much on the libsystemd
thing. I know people like to hit on systemd,



I know, and one of the problems that results from having just a torrent 
of undeserved criticism is that it naturally predisposes the maintainers 
to reflexively disregard all criticism.  To be clear: I *like* systemd.  
One of the things I like about it is that while the project is fairly 
large, the individual functions/services are modular and mostly 
independent of each other.  But that isn't really true of libsystemd.  I 
understand that there are some dependencies between different components 
of libsystemd, but sd-daemon doesn't seem to have any dependencies on 
sd-journal, for example.




but the attacker could
have used various other vehicle libs for their goal, too. I mean, sshd
uses PAM, and that pull in variety of things through its modules



PAM modules aren't a problem for the same reason that the compression 
libraries aren't a problem now that they're dlopen()ed.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

Chris Adams wrote:
> However, it's a good trigger to review Fedora's security approach in
> general (like 2FA use).

Using such an issue that made it through upstream 2FA and would also have 
made it through any 2FA enforcement in Fedora as an excuse to force 2FA on 
us is just pure nonsense.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

Matthew Miller wrote:
> I sometimes see unit test failures. The developer ran the tests, but not
> on S390.

Why would I want a test failure on such an exotic architecture to fail my 
build? The only reason Fedora supports that architecture at all is pressure 
from IBM. Basically nobody uses it.

Kevin Kofler

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

* Kilian Hanich via devel:

> Am 02.04.24 um 10:22 schrieb Florian Weimer:
>>>   - Can some wrappers be developed to make it both easier and safer?
>> GCC already provides function multi-versioning/target clones as a
>> higher-level interface.
>
>
> Also, upstreams should by default properly mark their stuffs with
> restrictive visibilities.
>
> While we are a few decades to change the defaults, that doesn't mean
> that one can't choose the better option. So, by default one should
> choose -fvisibility=hidden and mark the public API with
> __attribute__((visibility("protected"))) or, if they really want a
> function to be interpositionable (by e.g. LD_PRELOAD) as
> __attribute__((visibility("default"))).

I think protected visibility is still broken on x86-64.  For function
symbols, it's more convenient to use -fno-semantic-interposition and
rely on LTO to do the heavy lifting.  For data symbols, it may be a
better longer term investment to add explicit export lists (maybe even
with symbol versioning), and again rely on LTO to make everything else
hidden.

Thanks,
Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Simo Sorce

On Sat, 2024-03-30 at 15:23 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote:
> > Once upon a time, Michael Catanzaro  said:
> > > I agree that running autoreconf on our packages makes sense to start
> > > doing. Still, to avoid this backdoored m4 file, we would have needed
> > > to stop using release tarballs altogether and switch to using git
> > > tags directly instead. That would at least force the malicious
> > > attacker to commit their code to version control, making it slightly
> > > harder to hide the attack.
> > 
> > Using a signed tarball is ideally better than a git tag (it's an extra
> > level of author attestation)... but where both are available, it'd be
> > nice to have a way to denote in the spec file that there are two URLs
> > for the source.  In this case, if both URLs were listed and something
> > could be run to automatically fetch and compare them, the attack code
> > would have been flagged.
> 
> Tarball production should be reproducible. Then the maintainer can
> both make a signature locally and make it public, and users can download
> the auto-generated tarball.
> 
> In fact, github tarball generation is stable. A few years ago they tried
> to improve the compression method (i.e. .tar would be still identical,
> but .tar.gz would be different), and after a huge outcry this was reverted.
> They still haven't officially said that it's stable, but let's hope that
> it never changes, at least not without a suitable advance warning.

I do not know if this changed in the last couple of years, but tarballs
in github are not stable (or weren't up to a couple years ago), they
are cached for a period of time, so they may look stable in busy
projects where you have regular downloads that keep the cache alive,
but they are *regenerated* from the tag for seldom downloaded tarballs.
And when that happens then hashes change.

Simo.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc







--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

On Tue, Apr 02, 2024 at 12:45:18AM -0700, Gordon Messmer wrote:
> On 2024-04-01 23:59, Gordon Messmer wrote:
> >Now gdb can print the GOT with the paths providing the memory
> >section containing a function.  For example, on a Debian 12 system
> >with liblzma 5.6:
> 
> 
> Purely as trivia, and as I haven't seen it discussed elsewhere, the
> malware steals a different set of symbols on Fedora, where
> RSA_public_decrypt doesn't seem to appear in the GOT at all.  On
> Fedora 40:
> 
> gef➤  got RSA
> 
> GOT protection: Full RelRO | GOT functions: 503
> 
> [0x556ac0b94ff8] RSA_set0_key@OPENSSL_3.0.0  →  0x7f4e95dafce0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b951c0] RSA_bits@OPENSSL_3.0.0  →  0x7f4e95daf0a0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b951e0] EVP_PKEY_set1_RSA@OPENSSL_3.0.0  → 0x7f4e960e23b0 :
> /usr/lib64/liblzma.so.5.6.1
> [0x556ac0b95310] RSA_set0_crt_params@OPENSSL_3.0.0  → 0x7f4e95dafea0
> : /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b953c8] RSA_size@OPENSSL_3.0.0  →  0x7f4e95daf0b0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95518] RSA_new@OPENSSL_3.0.0  →  0x7f4e95db3330 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95778] RSA_get0_crt_params@OPENSSL_3.0.0  → 0x7f4e95dae490
> : /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95870] RSA_free@OPENSSL_3.0.0  →  0x7f4e95db2f00 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95b90] RSA_get0_key@OPENSSL_3.0.0  →  0x7f4e960e1ac0 :
> /usr/lib64/liblzma.so.5.6.1
> [0x556ac0b95c00] RSA_get0_factors@OPENSSL_3.0.0  →  0x7f4e95dae470 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95c88] EVP_PKEY_get1_RSA@OPENSSL_3.0.0  → 0x7f4e95d59710 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95da0] RSA_get_ex_data@OPENSSL_3.0.0  →  0x7f4e95db3440 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95e50] RSA_set0_factors@OPENSSL_3.0.0  →  0x7f4e95dafdc0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95f00] RSA_blinding_on@OPENSSL_3.0.0  →  0x7f4e95db17f0 :
> /usr/lib64/libcrypto.so.3.2.1

Since no one else replied yet, this is a nice bit of analysis.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

On Tue, Apr 02, 2024 at 05:09:18PM +0200, Kilian Hanich via devel wrote:
> Am 02.04.24 um 10:22 schrieb Florian Weimer:
> >>  - Can some wrappers be developed to make it both easier and safer?
> >GCC already provides function multi-versioning/target clones as a
> >higher-level interface.
> 
> 
> Also, upstreams should by default properly mark their stuffs with
> restrictive visibilities.
> 
> While we are a few decades to change the defaults, that doesn't mean
> that one can't choose the better option. So, by default one should
> choose -fvisibility=hidden and mark the public API with
> __attribute__((visibility("protected"))) or, if they really want a
> function to be interpositionable (by e.g. LD_PRELOAD) as
> __attribute__((visibility("default"))).

ISTR this also makes the library faster (faster loading I think?)

Anyway we've done it for all the virt libraries for years.

Rich.

> As a side effect, if you ever want your library be usable on Windows,
> you need to do that anyway since hidden is the default there and your
> public API must be marked explicitly. (Also, Windows doesn't support
> interposition and also doesn't support cyclic library dependencies
> without complicated hacks. So yeah, Windows kinda has the better
> defaults here.)
> 
> Some newer languages do that anyway already, but we obviously can't just
> change it for C and C++ projects.
> 
> But depending on the architecture this may not necessarily be possible.
> So yeah, only upstream can do that, not us.
> 
> 
> Regards
> 
> Kilian Hanich
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Kilian Hanich via devel


Am 02.04.24 um 10:22 schrieb Florian Weimer:

  - Can some wrappers be developed to make it both easier and safer?

GCC already provides function multi-versioning/target clones as a
higher-level interface.



Also, upstreams should by default properly mark their stuffs with
restrictive visibilities.

While we are a few decades to change the defaults, that doesn't mean
that one can't choose the better option. So, by default one should
choose -fvisibility=hidden and mark the public API with
__attribute__((visibility("protected"))) or, if they really want a
function to be interpositionable (by e.g. LD_PRELOAD) as
__attribute__((visibility("default"))).

As a side effect, if you ever want your library be usable on Windows,
you need to do that anyway since hidden is the default there and your
public API must be marked explicitly. (Also, Windows doesn't support
interposition and also doesn't support cyclic library dependencies
without complicated hacks. So yeah, Windows kinda has the better
defaults here.)

Some newer languages do that anyway already, but we obviously can't just
change it for C and C++ projects.

But depending on the architecture this may not necessarily be possible.
So yeah, only upstream can do that, not us.


Regards

Kilian Hanich
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Vít Ondruch



Dne 30. 03. 24 v 18:26 Artem S. Tashkinov via devel napsal(a):

Hi,

It was sheer luck that the exploit was discovered and major distros haven't yet 
included it in their stable releases. It's quite possible and plausible it 
could have reached RHEL, Debian, Ubuntu, SLES and other distros and it's almost 
reached Fedora 40.

I don't know how to talk to RedHat/IBM/FSF/Ubuntu and all the big players 
behind Open Source/Linux but I want to raise a very important issue.

There's near zero accountability for the tens of thousands of packages included in Linux 
distros, often by maintainers who have no resources, qualifications or even know any 
programming languages to spot the "bad" code and raise an alarm. Upstream 
packages are pushed into Linux distros without considerationand that's it.

That's all completely unacceptable on multiple levels. Security is a joke as a result of 
this considering the infamous "Jia Tan" who was almost the sole maintainer of 
XZ for over two years.

I propose this issue to be tackled in a centralized way by the collaboration of 
major distros.



If I was JT, I would applaud this proposal. This would give me an 
opportunity to infiltrate such powerful body and either


1) close my eyes above some of the reviewed content from the right 
parties or


2) have some nice proposal such as "do you think your code is correct 
and won't you include rather this specially crafted piece of  code?"



But since I am not JT, I prefer the current decentralized approach.


Vít




There must be a website or a central authority which includes known to be 
good/safe/verified/vetted open source packages along with e.g. 
SHA256/384/512/whatever hashes of the source tarballs. In addition, the source 
tarballs (not their compressed versions because people may use different 
compressors and compression settings) and their hashes must be digitally signed 
or have the appropriate PGP signatures from the trusted parties.

Some parties must be assigned trust to be able to push new packages to this 
repository. Each push must be verified by at least two independent parties, 
let's say RedHat and Ubuntu or Ubuntu and Arch, it doesn't matter. The 
representatives of these parties must be people whose whereabouts are known to 
confirm who they physically are. No nicknames allowed.

This website must also have/allow a revocation mechanism for situations like 
this.

Now Fedora/Arch/Debian/Ubuntu/whatever distros can build packages knowing they 
are safe to use.

If that's the wrong place to come up with this proposal, please forward it to 
the people who are responsible for making such decisions. I'm not willing to 
dig through the dirt to understand how the Fedora project works, who is 
responsible for what, and what are the appropriate communication channels. If 
you care, you'll simply forward my message. Thanks a lot.

Best regards,
Artem
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Vít Ondruch

Dne 30. 03. 24 v 22:14 Zbigniew Jędrzejewski-Szmek napsal(a):

On Sat, Mar 30, 2024 at 08:00:29PM +0100, Kevin Kofler via devel wrote:

Zbigniew Jędrzejewski-Szmek wrote:

I think there's some useful points here, but this would need to be
qualified and/or made more flexible to be applied.

For example, systemd repo has fuzzer case files, which are a mix of
text, mojibake, and actual binary protocol samples. For example, dhcp
input packets, dns packets. There are also other ~binary test files,
for example corrupted journal files.

The tests are defined via meson.build, so those files are "referred to
in the build tools", and would not be allowed by the above definition.
But if we dropped those, we'd lose very valuable testing of the codebase.

On the other hand, "test files" are exactly how the payload of this backdoor
was disguised! So a policy that deletes all binary test files or even all
test files altogether would have prevented this backdoor.

Well, if we made a rule that "binary" files are not allowed

I think that we should really not talk about binary files and talk e.g.
about pre-generated files instead. This chapter in guidelines is already
trying to cover this:

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#pregenerated-code

But maybe we should rewrite the "No inclusion of pre-built binaries or
libraries" chapter above to be more generic.

Vít

, the
attacker would e.g. commit some minified bash that generates whatever output
is needed. The real problem was the complex and unreadable build system
that made it easy to embed _multiple_ obfuscated components for the attack.

To trust code, it needs to be reviewed. And if the code is reviewed,
and the build system is sane, it's usually fairly easy to say "oh,
this is a sample and the only way it's used is as input to a fuzzer
binary", or "this sample is used as input to a unit test", etc.

A policy against binary files would hinder this particular implementation
of the attack, but the attacker had full control of the repo, so they
would be able to arrange the attack around such a policy without too
much trouble.

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

* Lennart Poettering:

> On Sa, 30.03.24 18:56, Fedora Development ML (devel@lists.fedoraproject.org) 
> wrote:
>
>> > In systemd git main, libsystemd is only linked to libc, libcap,
>> > and libgcrypt + libgpg-error. A pull request to convert that that last
>> > pair to dlopen is under review.
>>
>> That helps somewhat (it would have prevented this backdoor from working),
>> but it also makes things even less transparent: How do we know whether some
>> random sd_foobarify() function or some random foobard linked against
>> libsystemd will (always or ever (and when?)) end up dlopening liblzma or
>> not?
>>
>> Distribution packagers tend to dislike dlopen due to the hidden dependencies
>> it introduces.
>
> Well, this is certainly a valid point, but the solution is not to make
> all deps hard ones. Instead, in order to just make these deps visible
> I see multiple better alternatives:
>
> 1. teach Linux/ELF something inspired by MacOS's weak deps. i.e. allow
>ELF programs declare that some symbols shall be backed by some lib,
>but make it a weak dep that is only resolved on demand, and
>gracefully is set to NULL if the library cannot be found. If we had
>that, we'd stop using dlopen() for systemd's deps, since all we do
>is basically reimplement this concept manually.

How exactly is this implemented?  Is the object loaded on the first
function call?  I'd be worried that this made initialization even more
complicated than it is today.

Loading the object unconditionally (prior to the function call) doesn't
make a difference for objects which are always installed on the system.
They would always be loaded.

Thanks,
Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Lennart Poettering

On Sa, 30.03.24 13:18, Gordon Messmer (gordon.mess...@gmail.com) wrote:

> On 2024-03-30 02:37, Richard W.M. Jones wrote:
> > (3) We should have a "security path", like "critical path".
> >
> > sshd is linked to a lot of libraries:
>
>
> I really don't want to start a systemd thread, but... the xz, lz4, and zstd
> libraries are pulled in by libsystemd, merely so that sshd can call
> "sd_notify" 
> (https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch),
> which raises a couple of questions.
>
> The first one that comes to mind is: Is the increased attack surface
> incurred by linking to these additional libraries worth the value provided
> by calling "sd_notify", or should that patch be dropped to improve sshd
> security?

As discussed elsewhere: these deps are now dlopen() in systemd git
main. So they are basically gone, unless you actually use one of the
API calls that need the code.

> The second is: Is libsystemd too large?  I could very easily be misreading
> it, but it looks like at least some of src/libsystemd/sd-journal is used by
> journald, including the compression bits.  Do those really belong in
> libsystemd?

There are various programs that use sd-journal to read journal
files. It's after all *the* place to you get your logs from these
days. And journal files can be compressed. We only use one compressor
when writing, but we have changed the compression library
(i.e. nowadays use zstd), and need to provide read
compatibility. Hence the other compression libs.

> If they need to be shared components, could the journald
> components be split out to reduce the size of libsystemd?  (That is, to
> avoid linking to the compression libs?)

This creates many other problems. For an explanation see the various
comments here: https://github.com/systemd/systemd/issues/32028

Also, I don't think we should get hung up too much on the libsystemd
thing. I know people like to hit on systemd, but the attacker could
have used various other vehicle libs for their goal, too. I mean, sshd
uses PAM, and that pull in variety of things through its modules, and
that's just very hard to properly review even when one just focusses
on the default PAM config on Fedora.

Lennart

--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Lennart Poettering

On Sa, 30.03.24 18:56, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> > In systemd git main, libsystemd is only linked to libc, libcap,
> > and libgcrypt + libgpg-error. A pull request to convert that that last
> > pair to dlopen is under review.
>
> That helps somewhat (it would have prevented this backdoor from working),
> but it also makes things even less transparent: How do we know whether some
> random sd_foobarify() function or some random foobard linked against
> libsystemd will (always or ever (and when?)) end up dlopening liblzma or
> not?
>
> Distribution packagers tend to dislike dlopen due to the hidden dependencies
> it introduces.

Well, this is certainly a valid point, but the solution is not to make
all deps hard ones. Instead, in order to just make these deps visible
I see multiple better alternatives:

1. teach Linux/ELF something inspired by MacOS's weak deps. i.e. allow
   ELF programs declare that some symbols shall be backed by some lib,
   but make it a weak dep that is only resolved on demand, and
   gracefully is set to NULL if the library cannot be found. If we had
   that, we'd stop using dlopen() for systemd's deps, since all we do
   is basically reimplement this concept manually.

2. without Linux/ELF supporting the above we could still teach systemd
   and other tools in similar situations to declare the dlopen deps
   they have in some ELF note or section, so that it can be processed
   by initrd generators, automatic dep generators in dpkg/rpm,
   ldd-like tools and everything else that wants this info. This would
   require some C macro magic, but could be added in probably just a
   few lines of codes added to relevant projects.

Lennart

--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

* Gordon Messmer:

> Why doesn't dlopen() solve the problem?  As best I understand it,
> liblzma was able to steal one (or more) of the symbols from
> libcrypto.so.3 because it ran constructors at a point in time when the
> GOT was still writable.  After loading shared objects is complete,
> that table is made read-only.  If dlopen() is used after the program
> starts, then even if the library is loaded, it can't steal symbols in
> the table any more.

The rsa_pkcs1_ossl_meth variable that contains a function pointer to the
actual implementation resides in read-write memory:

static RSA_METHOD rsa_pkcs1_ossl_meth = {
"OpenSSL PKCS#1 RSA",
rsa_ossl_public_encrypt,
rsa_ossl_public_decrypt, /* signature verification */
rsa_ossl_private_encrypt,/* signing */
rsa_ossl_private_decrypt,
rsa_ossl_mod_exp,
BN_mod_exp_mont,/* XXX probably we should not use Montgomery
 * if e == 3 */
rsa_ossl_init,
rsa_ossl_finish,
RSA_FLAG_FIPS_METHOD,   /* flags */
NULL,
0,  /* rsa_sign */
0,  /* rsa_verify */
NULL,   /* rsa_keygen */
NULL/* rsa_multi_prime_keygen */
};

The missing “const” keyword is probably an oversight, but I don't think
it matters because the variable is not used directly.  All access
happens through deefault_RSA_meth:

static const RSA_METHOD *default_RSA_meth = _pkcs1_ossl_meth;

void RSA_set_default_method(const RSA_METHOD *meth)
{
default_RSA_meth = meth;
}

const RSA_METHOD *RSA_get_default_method(void)
{
return default_RSA_meth;
}

const RSA_METHOD *RSA_PKCS1_OpenSSL(void)
{
return _pkcs1_ossl_meth;
}

And that's clearly required to be read-write.  RSA_set_default_method is
a documented interface, too.  So I don't think GOT patching was required
to achieve the intended effect.

Furthermore, it's possible to undo the effect of RELRO with mprotect.

Using dlopen, liblzma would not have been loaded at run time, but it's
not clear if it had mattered because liblzma would still have been
loaded by RPM, both at build and install time.

Thanks,
Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Apr 02, 2024 at 02:00:52AM -0700, Gordon Messmer wrote:
> On 2024-03-30 09:12, Neal Gompa wrote:
> > Note that dlopen() doesn't fix the problem of the giant libsystemd in
> > the first place. It just obfuscates the true dependency graph of
> > libsystemd.
> 
> 
> This isn't my area of expertise, but I am curious:
> 
> Why doesn't dlopen() solve the problem?  As best I understand it, liblzma
> was able to steal one (or more) of the symbols from libcrypto.so.3 because
> it ran constructors at a point in time when the GOT was still writable. 
> After loading shared objects is complete, that table is made read-only.  If
> dlopen() is used after the program starts, then even if the library is
> loaded, it can't steal symbols in the table any more.
> 
> Or do I misunderstand this entirely?

You understood correctly ;)

As you wrote, dlopen() is done after RELRO has taken effect.

Also, dlopen() is only called lazily when the required library is to
be used for the first time… So in this particular case, the program
could call sd_notify(), but no dlopen() call would be done.

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

On Tue, Apr 02, 2024 at 10:59:10AM +0200, Florian Weimer wrote:
> * Richard W. M. Jones:
> > In the xz case this wouldn't have been enough, it turns out we would
> > also have to delete m4/build-to-host.m4, which then autoreconf
> > regenerates.  I don't fully understand why that is.
> 
> I would expect that's what the serial number is for?  But that's just a
> guess.

Yes, in this case the attacker had set the serial number to 30, but
the latest upstream serial number was 3.  autoreconf won't replace the
file in this case unless it is deleted.  There really should be an
"always replace if you can" option in autoreconf.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Neal Gompa

On Tue, Apr 2, 2024 at 4:59 AM Florian Weimer  wrote:
>
> * Richard W. M. Jones:
>
> > I'm not pretending these will solve everything, but they should make
> > attacks a little harder in future.
> >
> >
> > (1) We should routinely delete autoconf-generated cruft from upstream
> > projects and regenerate it in %prep.  It is easier to study the real
> > source rather than dig through the convoluted, generated shell script
> > in an upstream './configure' looking for back doors.
> >
> > For most projects, just running "autoreconf -fiv" is enough.
> >
> > Yes, there are some projects that depend on a specific or old version
> > of autoconf.  We should fix those.  But that doesn't need to delay us
> > from using autoreconf on many projects today.
>
> Not shipping the m4 files and other artifacts required for regenerating
> autoconf scripts is not exactly rare, unfortunately.  I have filed a
> bunch of bugs because it's my understanding that this incomplete source
> code is against Fedora policies, but in the end, there isn't much we can
> do about it.
>
> But I sympathize with this approach, we should build from sources as
> much as we can.  Maybe not regenerate everything in %prep though, this
> really belongs into %build.  It's invoking a compiler, after all.
>

We have a %conf stage for this purpose. We should start using it.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder


On 2024-03-30 09:12, Neal Gompa wrote:

Note that dlopen() doesn't fix the problem of the giant libsystemd in
the first place. It just obfuscates the true dependency graph of
libsystemd.



This isn't my area of expertise, but I am curious:

Why doesn't dlopen() solve the problem?  As best I understand it, 
liblzma was able to steal one (or more) of the symbols from 
libcrypto.so.3 because it ran constructors at a point in time when the 
GOT was still writable.  After loading shared objects is complete, that 
table is made read-only.  If dlopen() is used after the program starts, 
then even if the library is loaded, it can't steal symbols in the table 
any more.


Or do I misunderstand this entirely?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

* Richard W. M. Jones:

> I'm not pretending these will solve everything, but they should make
> attacks a little harder in future.
>
>
> (1) We should routinely delete autoconf-generated cruft from upstream
> projects and regenerate it in %prep.  It is easier to study the real
> source rather than dig through the convoluted, generated shell script
> in an upstream './configure' looking for back doors.
>
> For most projects, just running "autoreconf -fiv" is enough.
>
> Yes, there are some projects that depend on a specific or old version
> of autoconf.  We should fix those.  But that doesn't need to delay us
> from using autoreconf on many projects today.

Not shipping the m4 files and other artifacts required for regenerating
autoconf scripts is not exactly rare, unfortunately.  I have filed a
bunch of bugs because it's my understanding that this incomplete source
code is against Fedora policies, but in the end, there isn't much we can
do about it.

But I sympathize with this approach, we should build from sources as
much as we can.  Maybe not regenerate everything in %prep though, this
really belongs into %build.  It's invoking a compiler, after all.

> In the xz case this wouldn't have been enough, it turns out we would
> also have to delete m4/build-to-host.m4, which then autoreconf
> regenerates.  I don't fully understand why that is.

I would expect that's what the serial number is for?  But that's just a
guess.

> (2) We should discourage gnulib as much as possible.

Or use Git sources without bundled gnulib, and re-bundled at build time
using gnulib-devel.  It would make gnulib updates easier.  Such updates
are sometimes required because gnulib overrides glibc internals without
much coordination, and gnulib-using software may fail to build (or run)
until gnulib is updated to reflect the internal glibc changes.

However, while I don't particularly like autoconf and gnulib (they are
mainly there to support systems other than GNU/Linux, most of them
proprietary), I don't expect any steps we take there to stop anyone who
targets Fedora specifically.  Being different from other distributions
doesn't help at all if Fedora is the target.

> (3) We should have a "security path", like "critical path".

I think there is a strong overlap with a bootstrap package set that is
occasionally discussed.  And this leads to the main point I want to
make:

Stopping an attack that has already happened does not make much sense.
Given that we work in the open, preventing future attacks that target
Fedora specifically is likely impossible.  Therefore, the focus should
be on builder and buildroot integrity, and generic strategies for
restoring buildroot integrity after an incident.  In this particular
case, so far we considered it sufficient to merely downgrade one
package.  But the package in question was part of the default buildroot.
That means that in theory, it could have persisted itself outside the
confines of its own package.

> sshd is linked to a lot of libraries:
>
> /lib64/libaudit.so.1audit-libs
> /lib64/libc.so.6glibc
> /lib64/libcap-ng.so.0   libcap-ng
> /lib64/libcap.so.2  libcap
> /lib64/libcom_err.so.2  libcom_err
> /lib64/libcrypt.so.2libxcrypt
> /lib64/libcrypto.so.3   openssl-libs
> /lib64/libeconf.so.0libeconf
> /lib64/libgcc_s.so.1libgcc
> /lib64/libgssapi_krb5.so.2  krb5-libs
> /lib64/libk5crypto.so.3 krb5-libs
> /lib64/libkeyutils.so.1 keyutils-libs
> /lib64/libkrb5.so.3 krb5-libs
> /lib64/libkrb5support.so.0  krb5-libs
> /lib64/liblz4.so.1  lz4-libs
> /lib64/liblzma.so.5 xz-libs
> /lib64/libm.so.6glibc
> /lib64/libpam.so.0  pam-libs
> /lib64/libpcre2-8.so.0  pcre2
> /lib64/libresolv.so.2   glibc
> /lib64/libselinux.so.1  libselinux
> /lib64/libsystemd.so.0  systemd-libs
> /lib64/libz.so.1zlib / zlib-ng
> /lib64/libzstd.so.1 zstd
>
> Should we have a higher level of attention to these packages?  We
> already have "critical path", but that's a broad category now.  These
> seem like they are "security path" packages, an intentionally small
> subset associated with very secure services which are enabled by
> default.

The bootstrap set depends on SWIG, and SWIG pulls in language
implementations which are not bootstrapped from source using the
previous version.

Thanks,
Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Panu Matilainen


On 4/1/24 14:46, Neal Gompa wrote:

On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek
 wrote:


On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote:

On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:

Adam,

Is there a way already to achieve test isolation during the rpm build?


Nothing systematic that I'm aware of, no. It would be tricky because
there is no one universal Standard Test System (not even within a
single language ecosystem, let alone across all of them). Currently
you'd have to design something unique, if you wanted to implement this
for your package.


If we wanted to pursue that, I'd suggest the following:
remount $RPM_BUILD_ROOT read-only for the %check phase
(or maybe overmount it with a writable overlayfs that is thrown
away after %check finishes, and warn if any modifications were made.)
%check is executed after %install, so everything should be in place
before %check, and %check may be skipped, so no modifications to
installed files should be done in %check.

Considering possible implemention details, machinectl has 'bind' and
'bind --read-only' that might be useful here. But mock uses
systemd-nspawn in a way that does register the container with machined.
So maybe it'd be more reasonable to just execute a mount command directly
from mock.

This is independent of the test system and does not require splitting
of the test sources.



Another thing to consider is making RPM unshare each build phase like
it can for scriptlets now at install time[1].

Sandboxing and limiting in rpmbuild itself like we can with rpm can
also help with this. I believe moss[2]' boulder tool does this.

[1]: https://github.com/rpm-software-management/rpm/pull/2666
[2]: https://github.com/serpent-os/moss/tree/main/boulder


Sure, this is an area we've been planning to look into even before this 
incident. For example 
https://github.com/rpm-software-management/rpm/issues/2989 and as a 
result of this thread, 
https://github.com/rpm-software-management/rpm/issues/3010. And builds 
with a read-only source: 
https://github.com/rpm-software-management/rpm/issues/2985


None of this will fix a compromised usptream of course.

- Panu -
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-02 Thread Andreas Schneider

On Tuesday, 2 April 2024 09:52:38 CEST Richard W.M. Jones wrote:
> On Tue, Apr 02, 2024 at 07:40:33AM +0200, Andreas Schneider wrote:
> > On Saturday, 30 March 2024 10:37:44 CEST Richard W.M. Jones wrote:
> > > These are just my thoughts on a Saturday morning.  Feedback welcome of
> > > course.
> > 
> > I find the use of the ifunc attribute is really uncommon at this place. I
> > would expect it in ffmpeg or some media codecs. In xz it looks like it is
> > only there to hook in the payload. The software I know normally uses
> > target cloning.
> 
> In hindsight it's suspicious, but it's not generally suspicious for a
> project that needs to generate optimal code for different
> sub-architectures (eg. something that does fast decompression) to use
> the mechanism for that purpose, ifunc.
> 
> That said, ifunc is a very complicated, fragile  but powerful mechanism
> and I'd like to know from the glibc developers what we should
> look out for.  For example:
> 
>  - Is it ever valid for ifunc to take control of functions in another
>library?  Can this be detected by ld.so?
> 
>  - Can some wrappers be developed to make it both easier and safer?

Well, if it would do that. I took a quick look at xz and didn't see any 
specific code for an architecture flavor like x86_64-v3 or avx related. It 
lacks the implementation for that. All it did was adding the infrastructure 
without using it. I guess that the use of ifunc would is still be very rare.

Target clones is what you normally see.

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

* Richard W. M. Jones:

> That said, ifunc is a very complicated, fragile  but powerful mechanism
> and I'd like to know from the glibc developers what we should
> look out for.  For example:
>
>  - Is it ever valid for ifunc to take control of functions in another
>library?  Can this be detected by ld.so?

I'm not sure what you mean by “take control”.  The IFUNC resolver
returns an address that is used as the symbol value, for the specific
symbol the IFUNC resolver was associated with at build time.  It's not
expected to write to ld.so? data structures directly.

I have patches which make key ld.so? data structures read-only, but they
still have to be read-write during relocation processing, when IFUNC
resolvers run.  Under the defend-against-application-bugs model, that's
a reasonable trade-off because IFUNC resolvers are unlikely to have
vulnerabilities (currently, they cannot even access environment
variables reliably).  Of course, it doesn't work for IFUNC resolvers
written with malicious intent.  I don't think there is a reasonable
possibility to defend against that because any ld.so? defense we create
is out there for everyone to see, so they can work around that.

>  - Can some wrappers be developed to make it both easier and safer?

GCC already provides function multi-versioning/target clones as a
higher-level interface.

Thanks,
Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

On Tue, Apr 02, 2024 at 07:40:33AM +0200, Andreas Schneider wrote:
> On Saturday, 30 March 2024 10:37:44 CEST Richard W.M. Jones wrote:
> > These are just my thoughts on a Saturday morning.  Feedback welcome of
> > course.
> 
> I find the use of the ifunc attribute is really uncommon at this place. I 
> would expect it in ffmpeg or some media codecs. In xz it looks like it is 
> only 
> there to hook in the payload. The software I know normally uses target 
> cloning.

In hindsight it's suspicious, but it's not generally suspicious for a
project that needs to generate optimal code for different
sub-architectures (eg. something that does fast decompression) to use
the mechanism for that purpose, ifunc.

That said, ifunc is a very complicated, fragile  but powerful mechanism
and I'd like to know from the glibc developers what we should
look out for.  For example:

 - Is it ever valid for ifunc to take control of functions in another
   library?  Can this be detected by ld.so?

 - Can some wrappers be developed to make it both easier and safer?

> I think the use of the ifunc attribute should be a red flag. Can't we check 
> for it with rpmlint and let the security team verify it?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder


On 2024-04-01 23:59, Gordon Messmer wrote:
Now gdb can print the GOT with the paths providing the memory section 
containing a function.  For example, on a Debian 12 system with 
liblzma 5.6: 



Purely as trivia, and as I haven't seen it discussed elsewhere, the 
malware steals a different set of symbols on Fedora, where 
RSA_public_decrypt doesn't seem to appear in the GOT at all.  On Fedora 40:


gef➤  got RSA

GOT protection: Full RelRO | GOT functions: 503

[0x556ac0b94ff8] RSA_set0_key@OPENSSL_3.0.0  →  0x7f4e95dafce0 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b951c0] RSA_bits@OPENSSL_3.0.0  →  0x7f4e95daf0a0 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b951e0] EVP_PKEY_set1_RSA@OPENSSL_3.0.0  → 0x7f4e960e23b0 : 
/usr/lib64/liblzma.so.5.6.1
[0x556ac0b95310] RSA_set0_crt_params@OPENSSL_3.0.0  → 0x7f4e95dafea0 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b953c8] RSA_size@OPENSSL_3.0.0  →  0x7f4e95daf0b0 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b95518] RSA_new@OPENSSL_3.0.0  →  0x7f4e95db3330 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b95778] RSA_get0_crt_params@OPENSSL_3.0.0  → 0x7f4e95dae490 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b95870] RSA_free@OPENSSL_3.0.0  →  0x7f4e95db2f00 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b95b90] RSA_get0_key@OPENSSL_3.0.0  →  0x7f4e960e1ac0 : 
/usr/lib64/liblzma.so.5.6.1
[0x556ac0b95c00] RSA_get0_factors@OPENSSL_3.0.0  →  0x7f4e95dae470 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b95c88] EVP_PKEY_get1_RSA@OPENSSL_3.0.0  → 0x7f4e95d59710 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b95da0] RSA_get_ex_data@OPENSSL_3.0.0  →  0x7f4e95db3440 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b95e50] RSA_set0_factors@OPENSSL_3.0.0  →  0x7f4e95dafdc0 : 
/usr/lib64/libcrypto.so.3.2.1
[0x556ac0b95f00] RSA_blinding_on@OPENSSL_3.0.0  →  0x7f4e95db17f0 : 
/usr/lib64/libcrypto.so.3.2.1

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder


On 2024-03-30 13:18, Gordon Messmer wrote:


The write up describing the back door indicates that the malicious xz 
library "changes the value of rsa_public_decr...@plt to point to 
its own code."  So the back door has pointed one of the symbols that 
should point to a page mapped to OpenSSL's libcrypto.so.3 to a page 
mapped to liblzma.so.5, instead.


Would it be possible to audit the value of a process's symbols at 
runtime to look for this kind of shenanigans?  Could this type of 
auditing be added to functional tests or rpminspect?




As a proof of concept, I extended GEF a tiny bit: 
https://github.com/gordonmessmer/gef


Now gdb can print the GOT with the paths providing the memory section 
containing a function.  For example, on a Debian 12 system with liblzma 5.6:


---

got RSA

GOT protection: Full RelRO | GOT functions: 463

[0x555957c780f8] RSA_set0_key@OPENSSL_3.0.0  →  0x7f7bce676c90 : 
/usr/lib/x86_64-linux-gnu/libcrypto.so.3
[0x555957c78218] RSA_public_decrypt@OPENSSL_3.0.0  → 0x7f7bce948510 : 
/usr/lib/x86_64-linux-gnu/liblzma.so.5
[0x555957c782a8] EVP_PKEY_set1_RSA@OPENSSL_3.0.0  → 0x7f7bce618f30 : 
/usr/lib/x86_64-linux-gnu/libcrypto.so.3

...

---


If the full table were collected and logged in functional testing, and 
compared from build to build, this seems like it could detect this class 
of attack.  RSA_public_decrypt has clearly moved from libcrypto.so.3 to 
liblzma.so.5.


Is this worth pursuing?

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Andreas Schneider

On Saturday, 30 March 2024 10:37:44 CEST Richard W.M. Jones wrote:
> These are just my thoughts on a Saturday morning.  Feedback welcome of
> course.

I find the use of the ifunc attribute is really uncommon at this place. I 
would expect it in ffmpeg or some media codecs. In xz it looks like it is only 
there to hook in the payload. The software I know normally uses target 
cloning.

I think the use of the ifunc attribute should be a red flag. Can't we check 
for it with rpmlint and let the security team verify it?

Best regards

Andreas

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder


Matthew Miller,

Unit tests, even though in theory developer should mock dependencies to 
isolate their code to the maximum, in reality, it is not that clear cut. 
Therefore, those unit tests do serve to some extent as a validation that 
their code works with the system libraries and platforms present in the 
targeted configuration. I think it is valuable to run them during the 
rpm builds, and contribute upstream when they break.


On 4/1/24 14:11, Matthew Miller wrote:

On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote:

Unit tests are something for upstream developers. They should NEVER be run
in a distribution build.


Even in the few little packages I'm still responsible for, I sometimes see
unit test failures. The developer ran the tests, but not on S390. Or, with a
different timezone database than current in Fedora. Or etc.



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder


Chris,
The specific points of entry were evading the strength of open source: 
many skilled eyes. Therefore, there is value in programmatically 
enforcing that everything used as an input in a build must have been 
exposed to *normal opensource workflows*. It is a very simple principle, 
yet very powerful: let's flag everything that can evade review: 
basically, tar.gz must be equal in content to what it is browseable on 
the git repository, and also blobs must be flagged for additional 
analysis, because released tar.gz and blobs are not normally reviewed on 
a opensource workflow.


Those problems can be codified in a tool (which it is already done in a 
proof of concept to show that it is simple to do and possible), or the 
approach can be changed all together to something like source-git?


On 4/1/24 18:47, Chris Adams wrote:

Yeah.  This was clearly an attack targeted at Fedora and Debian; trying
to fix the specific point of entry is a losing battle, as at the end of
the day, Fedora will still be taking code from upstreams and
distributing it to systems far and wide.  The particular use of test
and autoconf files to try to hide the attack may be novel, but there are
other ways it could have been done.  If there's easy and minimal-impact
ways to help (which I haven't really seen suggested), that's good to
look at, but putting lots of effort into how tests are run or wholesale
changes to configuration seem to not be all that useful.

However, it's a good trigger to review Fedora's security approach in
general (like 2FA use).


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Chris Adams

Once upon a time, Gabriel Somlo  said:
> IMHO, there's no good way to *programmatically* protect ourselves
> from a malicious upstream on which we depend. If their goal is to
> compromise us, they will work around whatever programmatic/technical
> measures we happen to have in place at the time they decide to launch
> their attack.

Yeah.  This was clearly an attack targeted at Fedora and Debian; trying
to fix the specific point of entry is a losing battle, as at the end of
the day, Fedora will still be taking code from upstreams and
distributing it to systems far and wide.  The particular use of test
and autoconf files to try to hide the attack may be novel, but there are
other ways it could have been done.  If there's easy and minimal-impact
ways to help (which I haven't really seen suggested), that's good to
look at, but putting lots of effort into how tests are run or wholesale
changes to configuration seem to not be all that useful.

However, it's a good trigger to review Fedora's security approach in
general (like 2FA use).

-- 
Chris Adams 
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Gabriel Somlo

> On Mon, Apr 1, 2024 at 17:11:46 -0400, Matthew Miller via devel wrote:
> On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote:
> > Unit tests are something for upstream developers. They should NEVER be run 
> > in a distribution build.
> 
> Even in the few little packages I'm still responsible for, I sometimes see
> unit test failures. The developer ran the tests, but not on S390. Or, with a
> different timezone database than current in Fedora. Or etc.

IMHO, there's no good way to *programmatically* protect ourselves
from a malicious upstream on which we depend. If their goal is to
compromise us, they will work around whatever programmatic/technical
measures we happen to have in place at the time they decide to launch
their attack.

Any potential defense against this sort of thing will have to be
*social*, and/or *process* based. Packagers should get to know (as
best as possible) their upstream maintainers and developers -- by
reaching out over upstream's dev fora, by meeting up at events and
conferences, etc. Packagers should hopefully be familiar with the
human *and* technical situation of upstream, and have a chance to
notice when things go "weird".

Just another $0.02 from the peanut gallery...

Cheers,
--Gabriel
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

On Mon, 2024-04-01 at 23:37 +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > > * Deleting ALL files automatically generated or imported by autotools in
> > > %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it
> > > would NOT have done the right thing here. Delete the files, THEN run
> > > autoreconf.)
> > 
> > No. This would not have avoided the attack, because it would not have
> > regenerated the malicious file. We have already established that.
> 
> Just running autoreconf would not. As I wrote: "DO NOT trust autoreconf, it 
> would NOT have done the right thing here." Deleting the file with an 
> explicit rm -f in %prep, and THEN running autoreconf would have regenerated 
> (reimported, actually, this comes from gnulib and is copied unchanged, but 
> in any case it would NOT have contained the malicious additions) the file.
> 
> That said, autoreconf needs fixing too, because -f is supposed to regenerate 
> all files that can be regenerated, which is not happening. But if you 
> explicitly delete the files before running autoreconf, then it has to 
> regenerate them no matter what.

Sure, but as others posted upthread, this still doesn't help much. To
do this you have to know what m4s are 'standard' and will actually be
regenerated, and which are custom and you can't wipe them. And then an
attacker could just slip in an extra custom one instead of modifying a
'standard' one.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Kevin Kofler via devel

Adam Williamson wrote:
>> * Deleting ALL files automatically generated or imported by autotools in
>> %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it
>> would NOT have done the right thing here. Delete the files, THEN run
>> autoreconf.)
> 
> No. This would not have avoided the attack, because it would not have
> regenerated the malicious file. We have already established that.

Just running autoreconf would not. As I wrote: "DO NOT trust autoreconf, it 
would NOT have done the right thing here." Deleting the file with an 
explicit rm -f in %prep, and THEN running autoreconf would have regenerated 
(reimported, actually, this comes from gnulib and is copied unchanged, but 
in any case it would NOT have contained the malicious additions) the file.

That said, autoreconf needs fixing too, because -f is supposed to regenerate 
all files that can be regenerated, which is not happening. But if you 
explicitly delete the files before running autoreconf, then it has to 
regenerate them no matter what.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Jakub Jelinek

On Mon, Apr 01, 2024 at 01:36:48PM -0400, Peter Jones wrote:
> Unrelated to the idea that some packages are special in this way, it's
> probably worth writing some static analysis tools we could put into
> rpm-inspect to detect when (a) a binary grows new public keys it didn't
> have before, and (b) a shared object grows a new ifunc.  The latter is
> dramatically easier, of course, but both of those should be pretty rare
> events, so they're worth further inspection.

I don't see much difference between ifuncs and any other library
constructors from the exploit POV, at least with DT_BIND_NOW both is just
some extra code run during library initialization.  Sure, ifunc handlers
affect what ifunc target is later called whenever calling the ifunc
function, but harm can be done already when loading the library or the
library constructor could overwrite function pointers, vtable pointers or
just some data in the library to change its behavior later.
So, in addition to watching for new ifuncs (and more importantly, trying to
figure out if it is possible to statically prove the set of possible
functions it will resolve to and compare to the old set; and if it isn't
possible to statically figure out list of possible targets flag it for more
careful inspection) we should watch for additions of
__attribute__((constructor)) code or C++ namespace scope non-trivial ctors or
dynamic initializers of namespace scope variables.

Jakub
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Matthew Miller

On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote:
> Unit tests are something for upstream developers. They should NEVER be run 
> in a distribution build.

Even in the few little packages I'm still responsible for, I sometimes see
unit test failures. The developer ran the tests, but not on S390. Or, with a
different timezone database than current in Fedora. Or etc.

-- 
Matthew Miller

Fedora Project Leader
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Peter Jones

> (3) We should have a "security path", like "critical path".
> 
> sshd is linked to a lot of libraries:
> 
> /lib64/libaudit.so.1audit-libs
> /lib64/libc.so.6glibc
> /lib64/libcap-ng.so.0   libcap-ng
> /lib64/libcap.so.2  libcap
> /lib64/libcom_err.so.2  libcom_err
> /lib64/libcrypt.so.2libxcrypt
> /lib64/libcrypto.so.3   openssl-libs
> /lib64/libeconf.so.0libeconf
> /lib64/libgcc_s.so.1libgcc
> /lib64/libgssapi_krb5.so.2  krb5-libs
> /lib64/libk5crypto.so.3 krb5-libs
> /lib64/libkeyutils.so.1 keyutils-libs
> /lib64/libkrb5.so.3 krb5-libs
> /lib64/libkrb5support.so.0  krb5-libs
> /lib64/liblz4.so.1  lz4-libs
> /lib64/liblzma.so.5 xz-libs
> /lib64/libm.so.6glibc
> /lib64/libpam.so.0  pam-libs
> /lib64/libpcre2-8.so.0  pcre2
> /lib64/libresolv.so.2   glibc
> /lib64/libselinux.so.1  libselinux
> /lib64/libsystemd.so.0  systemd-libs
> /lib64/libz.so.1zlib / zlib-ng
> /lib64/libzstd.so.1 zstd
> 
> Should we have a higher level of attention to these packages?  We
> already have "critical path", but that's a broad category now.  These
> seem like they are "security path" packages, an intentionally small
> subset associated with very secure services which are enabled by
> default.

I agree, but that brings us to the question of what to do about them
that's special.

Unrelated to the idea that some packages are special in this way, it's
probably worth writing some static analysis tools we could put into
rpm-inspect to detect when (a) a binary grows new public keys it didn't
have before, and (b) a shared object grows a new ifunc.  The latter is
dramatically easier, of course, but both of those should be pretty rare
events, so they're worth further inspection.

Even if it's just RSA keys that we search for, that would add some
benefit, and that's pretty easy if nobody has tried to cover their
tracks: scan a binary for a big power of two sized odd number followed
by a small prime number, and then filtering that with a more rigorous
prime test on the first number will detect RSA keys and probably very
little else.  Might be worth grepping for "- BEGIN" as well.

Just some thoughts, I'm sure we'll all have many more where these come
from.

-- 
Peter
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]

2024-04-01 Thread Gary Buhrmaster

On Mon, Apr 1, 2024 at 4:42 PM Adam Williamson
 wrote:

> I think we *are* part of a supply chain, regardless of any handwaving
> about The Open Source Model.

And, more importantly, the industry has agreed
to use the term supply chain.  Is the term
perhaps overloaded, or perhaps too
ill-defined/imprecise?  Sure.  But if one wants
to use a different term one would need to work
across the industry to change the term, and
that is not going to happen.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

Understood. However, at least for those unit tests run in the %check, it 
is going to be almost unfeasible, because of the variability of the way 
things are done in the different programming ecosystems. In Java, unit 
tests are nicely separated in a different folder (i.e., `src/test`), but 
in golang, it is mingled with the source code in `_test.go` files. In C, 
it depends on the programmers convention.


On 4/1/24 09:29, Adam Williamson wrote:

On Mon, 2024-04-01 at 05:58 -0700, Carlos Rodriguez-Fernandez wrote:

Test isolation is still assuming the attack comes in the test phase.


As I initially suggested it, it does not. My suggestion was that we
ensure the test code is not available to the prep / build / install
phases *at all*, and is only made available to the test phase.


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]

On Mon, 2024-04-01 at 12:27 -0400, Neal Gompa wrote:
> > 
> > ii) the fact that this attack reinforces the painful truth that
> > sophisticated attackers *are* extremely interested in attacking the
> > supply chain of which we form a significant component
> 
> Can we please reframe it for what it actually is? This is an attack on
> open source communities. "Supply chain" implies a lot of things that
> simply don't exist in open source development. Almost the entirety of
> the sophistication of the attack was social engineering, not technical
> engineering. There *are* technical things to improve, for sure, but
> let's not try to make it sound like it's a wholly technical thing that
> can be solved with technical solutions exclusively. There are people
> and community problems that need addressing too.

This feels like a derail, so splitting it into a separate subthread.

Honestly, I don't see how the first part of your paragraph relates to
the second. I agree with a lot of the second part, but not the first.

I think we *are* part of a supply chain, regardless of any handwaving
about The Open Source Model. If you are part of producing stuff that
people use to do Real Life Stuff, you are part of a supply chain. You
might want to disclaim various responsibilities for various reasons,
but you still are. If you don't want to be part of a supply chain, stop
supplying stuff. I get the argument that there's a difference between
putting a plank over a stream with a CROSS AT YOUR OWN RISK sign and
charging people to cross your toll bridge, but there are *also* some
similarities.

I agree that the social engineering aspects of this attack were very
significant (though I disagree that was "almost the entirety of the
sophistication" - the technical elements were also pretty
sophisticated). But I don't see why that leads to bikeshedding about
whether this is a "supply chain" attack or not. Why is a "social
engineering attack" not a supply chain attack, but a "technical attack"
is?
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

On Mon, 2024-04-01 at 05:58 -0700, Carlos Rodriguez-Fernandez wrote:
> Test isolation is still assuming the attack comes in the test phase.

As I initially suggested it, it does not. My suggestion was that we
ensure the test code is not available to the prep / build / install
phases *at all*, and is only made available to the test phase.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Neal Gompa

On Mon, Apr 1, 2024 at 12:22 PM Adam Williamson
 wrote:
>
> On Mon, 2024-04-01 at 10:56 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote:
> > > Adam Williamson wrote:
> > > > Maybe this needs to go on the growing pile of reasons why the
> > > > traditional Linux model *does* need to go away. Maybe Fedora, with its
> > > > foundation of First, should be kind of at the forefront of making that
> > > > happen.
> > >
> > > Switching to a container-based model is just going to introduce more
> > > different library versions (in the worst case, one per container) with a
> > > higher probability that one of them is compromised.
> >
> > Our traditional distro model is not perfect — far from it — and we
> > certainly try to improve it. But I agree with Kevin that in _this
> > particular case_, the other models have smaller chances of catching
> > the issue.
> >
> > Here the upstream was compromised, so 2FA, upstream signatures, and any
> > other checks don't help at all.
>
> Yes, to be clear, my "this" was not "the specific technical details of
> this attack". It was more:
>
> i) the factors I listed in my email about just how many people are
> trusted to build 'Fedora', when 'Fedora' is essentially a collection of
> arbitrary scripts executed as root
>
> ii) the fact that this attack reinforces the painful truth that
> sophisticated attackers *are* extremely interested in attacking the
> supply chain of which we form a significant component

Can we please reframe it for what it actually is? This is an attack on
open source communities. "Supply chain" implies a lot of things that
simply don't exist in open source development. Almost the entirety of
the sophistication of the attack was social engineering, not technical
engineering. There *are* technical things to improve, for sure, but
let's not try to make it sound like it's a wholly technical thing that
can be solved with technical solutions exclusively. There are people
and community problems that need addressing too.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

On Mon, 2024-04-01 at 10:56 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote:
> > Adam Williamson wrote:
> > > Maybe this needs to go on the growing pile of reasons why the
> > > traditional Linux model *does* need to go away. Maybe Fedora, with its
> > > foundation of First, should be kind of at the forefront of making that
> > > happen.
> > 
> > Switching to a container-based model is just going to introduce more 
> > different library versions (in the worst case, one per container) with a 
> > higher probability that one of them is compromised.
> 
> Our traditional distro model is not perfect — far from it — and we
> certainly try to improve it. But I agree with Kevin that in _this
> particular case_, the other models have smaller chances of catching
> the issue.
> 
> Here the upstream was compromised, so 2FA, upstream signatures, and any
> other checks don't help at all.

Yes, to be clear, my "this" was not "the specific technical details of
this attack". It was more:

i) the factors I listed in my email about just how many people are
trusted to build 'Fedora', when 'Fedora' is essentially a collection of
arbitrary scripts executed as root

ii) the fact that this attack reinforces the painful truth that
sophisticated attackers *are* extremely interested in attacking the
supply chain of which we form a significant component
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Scott Schmit

On Mon, Apr 01, 2024 at 02:23:19PM -, François Rigault wrote:
> > Those blobs were not in systemd,
> 
> that was not my point, nevertheless putting it this way: nobody knows.
> 
> For the example about compression methods you could generate your binary 
> using a piece of code, that can be reviewed (maybe using a fixed seed as 
> inspired by
> https://git.rootprojects.org/root/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89
>  btw!). If you want to test systemd against a broken journal then can't you 
> commit a valid journal (that can be reviewed) and some code that generates a 
> corrupted one?
> 
> The obfuscated C code is a different problem - at least it can be 
> reviewed/audited and the maintainer can ask to simplify it.
> 
> My point is that everything should get reviewed before merge. I would hope 
> that, as a lesson learnt from this attack, no unreviewed "corrupted binary" 
> exist anymore in any project, since really, nobody knows what they actually 
> contain.

Or (if production of the binary is expensive or can be fiddly), commit
the binary but include a script to generate it that can be run by others
to check that the included binary is legit.

Call it "Reproducible Tests" to go along with reproducible builds.

Cryptography has the same concept now, learning from the Dual EC DBRG
backdoor: https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number

So "nothing-up-my-sleeve scripts" could be another moniker.

-- 
Scott Schmit


smime.p7s
Description: S/MIME cryptographic signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Miroslav Suchý


Dne 01. 04. 24 v 3:16 dop. Kilian Hanich via devel napsal(a):

Also, I have seen build setups which encode the status of tests in the
eventual binary and as such info page or integrated bug report
generators. Often because some distros sometimes turned them off or
ships software even with failed tests and thus pushing that headache to
upstream. 


Can you point me to such case, please? Just being curious.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

Definitely this attack leveraged places where eyes don't look:
distributed tar.gz and blobs.

I put the PoC to flag those two in github[1]

Example output:

$ ./rpmseclint tests/rpmseclint-test.spec
-Diff-
~ test.txt
+ additional.txt
+ blob.txt.gz
-Blobs
application/gzip blob.txt.gz

Now, against the PoC itself, the diff part can be totally avoided by
using generated tars. Not all projects are in github, but those that
do... The other way is by using source-git?

Regarding the blobs part, ... an attack could still manage to fool
`file` with a crafted binary. However, that would still increase the
attack complexity.

[1] https://github.com/carlosrodfern/rpmseclint

On 3/31/24 19:02, Carlos Rodriguez-Fernandez wrote:

Regarding downstream defense, prohibiting blobs or differences between
tars and git repos may be overkill or difficult at this moment, but a
tool to assist maintainers in the identification and analysis of these
situations where attacks may be hidden into can be very helpful.

Regarding the latter, where you want to find diff between tars and git
repo content, someone may say "let's just use the github API to pull the
tar", but not all projects use github, or have that feature. So, I still
think there is value in these tools.

I started working on a PoC personal minitool named rpmseclint that
utilizes the "VCS" tag to pull the git repo, and the tar, and compares
and flags things for further review. Right now, I'm just focused on
blobs, and files/directories differences. The intention is to use it at
least right before a rebase. I'm just planning to personally use it to
get a "feel" for it (and help myself), but open to anyone wanting to
explore this idea.

In general, I think the idea of codifying security practices expertise
in tools to assist maintainers with detection and analysis has great
value; even if it is not enforcing anything at the moment. The
maintainer could then explicitly add found problems to an "ignore" list
after the analysis, and explain the "why" in the git commit body
message, and perpetuate the reasoning in the git history of the
downstream project. There is already a lot of best practices codified in
the gating pipelines, and I have found them extremely useful myself.

Regards,
Carlos R.F.

On 3/30/24 02:37, Richard W.M. Jones wrote:

I'm not pretending these will solve everything, but they should make
attacks a little harder in future.

(1) We should routinely delete autoconf-generated cruft from upstream
projects and regenerate it in %prep. It is easier to study the real
source rather than dig through the convoluted, generated shell script
in an upstream './configure' looking for back doors.

For most projects, just running "autoreconf -fiv" is enough.

Yes, there are some projects that depend on a specific or old version
of autoconf. We should fix those. But that doesn't need to delay us
from using autoreconf on many projects today.

In the xz case this wouldn't have been enough, it turns out we would
also have to delete m4/build-to-host.m4, which then autoreconf
regenerates. I don't fully understand why that is.

(2) We should discourage gnulib as much as possible.

In libvirt we took the decision a few years ago to remove gnulib.
It's extremely convoluted and almost no one understands how it really
works. It's written in obscure m4 macros and shell script.

It's also not necessary for Linux since gnulib is mainly about
porting to non-Linux platforms. There are better ways to do this.

In the xz case it was a gnulib-derived script which was modified to do
the initial injection (original:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD).

(3) We should have a "security path", like "critical path".

sshd is linked to a lot of libraries:

/lib64/libaudit.so.1 audit-libs
/lib64/libc.so.6 glibc
/lib64/libcap-ng.so.0 libcap-ng
/lib64/libcap.so.2 libcap
/lib64/libcom_err.so.2 libcom_err
/lib64/libcrypt.so.2 libxcrypt
/lib64/libcrypto.so.3 openssl-libs
/lib64/libeconf.so.0 libeconf
/lib64/libgcc_s.so.1 libgcc
/lib64/libgssapi_krb5.so.2 krb5-libs
/lib64/libk5crypto.so.3 krb5-libs
/lib64/libkeyutils.so.1 keyutils-libs
/lib64/libkrb5.so.3 krb5-libs
/lib64/libkrb5support.so.0 krb5-libs
/lib64/liblz4.so.1 lz4-libs
/lib64/liblzma.so.5 xz-libs
/lib64/libm.so.6 glibc
/lib64/libpam.so.0 pam-libs
/lib64/libpcre2-8.so.0 pcre2
/lib64/libresolv.so.2 glibc
/lib64/libselinux.so.1 libselinux
/lib64/libsystemd.so.0 systemd-libs
/lib64/libz.so.1 zlib / zlib-ng
/lib64/libzstd.so.1 zstd

Should we have a higher level of attention to these packages? We
already have "critical path", but that's a broad category now. These
seem like they are "security path" packages, an intentionally small

Re: Three steps we could take to make supply chain attacks a bit harder


I created a discussion issue for this idea:

https://github.com/rpm-software-management/rpm/discussions/3009

I think it worth pursuing further.

On 4/1/24 04:46, Neal Gompa wrote:

On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek
 wrote:


On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote:

On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:

Adam,

Is there a way already to achieve test isolation during the rpm build?


Nothing systematic that I'm aware of, no. It would be tricky because
there is no one universal Standard Test System (not even within a
single language ecosystem, let alone across all of them). Currently
you'd have to design something unique, if you wanted to implement this
for your package.


If we wanted to pursue that, I'd suggest the following:
remount $RPM_BUILD_ROOT read-only for the %check phase
(or maybe overmount it with a writable overlayfs that is thrown
away after %check finishes, and warn if any modifications were made.)
%check is executed after %install, so everything should be in place
before %check, and %check may be skipped, so no modifications to
installed files should be done in %check.

Considering possible implemention details, machinectl has 'bind' and
'bind --read-only' that might be useful here. But mock uses
systemd-nspawn in a way that does register the container with machined.
So maybe it'd be more reasonable to just execute a mount command directly
from mock.

This is independent of the test system and does not require splitting
of the test sources.



Another thing to consider is making RPM unshare each build phase like
it can for scriptlets now at install time[1].

Sandboxing and limiting in rpmbuild itself like we can with rpm can
also help with this. I believe moss[2]' boulder tool does this.

[1]: https://github.com/rpm-software-management/rpm/pull/2666
[2]: https://github.com/serpent-os/moss/tree/main/boulder




--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread François Rigault

> Those blobs were not in systemd,

that was not my point, nevertheless putting it this way: nobody knows.

For the example about compression methods you could generate your binary using 
a piece of code, that can be reviewed (maybe using a fixed seed as inspired by
https://git.rootprojects.org/root/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89
 btw!). If you want to test systemd against a broken journal then can't you 
commit a valid journal (that can be reviewed) and some code that generates a 
corrupted one?

The obfuscated C code is a different problem - at least it can be 
reviewed/audited and the maintainer can ask to simplify it.

My point is that everything should get reviewed before merge. I would hope 
that, as a lesson learnt from this attack, no unreviewed "corrupted binary" 
exist anymore in any project, since really, nobody knows what they actually 
contain.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder