> On Apr 3, 2024, at 10:00 AM, Michael Matz <m...@suse.de> wrote:
>
> Hello,
>
> On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote:
>
>>>> Seems reasonable, but note that it wouldn't make any difference to
>>>> this attack. The liblzma library was modified to corrupt the sshd
>>>> binary, when sshd was linked against liblzma. The actual attack
>>>> occurred via a connection to a corrupt sshd. If sshd was running as
>>>> root, as is normal, the attacker had root access to the machine. None
>>>> of the attacking steps had anything to do with having root access
>>>> while building or installing the program.
>>
>> There does not seem a single good solution against something like this.
>>
>> My take a way is that software needs to become less complex. Do
>> we really still need complex build systems such as autoconf?
>
> Do we really need complex languages like C++ to write our software in?
> SCNR :) Complexity lies in the eye of the beholder, but to be honest in
> the software that we're dealing with here, the build system or autoconf
> does _not_ come to mind first when thinking about complexity.
>
> (And, FWIW, testing for features isn't "complex". And have you looked at
> other build systems? I have, and none of them are less complex, just
> opaque in different ways from make+autotools).
>
> Ciao,
> Michael.
I would tend to agree with that even given my limited exposure to alternatives.
One aspect of the present attack that needs to be cured is that -- as I
understand it -- the open source repository was fine but the kit as distributed
had been subverted. In other words, the standard assumption that the
repository actually corresponds to the released code was not valid. And
furthermore, that it wasn't unusual for the kit to contain different or
additional elements, just that it wasn't supposed to differ in malicious ways.
One possible answer is for all elements of kits to be made explicitly visible,
though generated files probably don't want to be held in a normal source
control system. Another possible answer is for consumers of kits to treat kits
as suspect, and have them unpacked and examined -- including any elements not
source controlled -- before acceptance. I think the first option is better
because it exposes these additional elements to ongoing scrutiny from the
entire community, rather than only one-time inspection by release managers who
are probably quite pressed for time.
Either way, the reasons for these extra files to exist and the manner in which
they are supposed to be generated would need to be both well documented and
readily reproducible by outside parties.
paul
