Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #268557 > unrolled thread

making Debian secure by default

Back to article view | Back to linux.debian.user

Contents

  making Debian secure by default Lee <ler762@gmail.com> - 2024-03-27 22:40 +0100
    Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 00:10 +0100
      Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 05:30 +0100
        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 14:40 +0100
          Re: making Debian secure by default Greg Wooledge <greg@wooledge.org> - 2024-03-28 16:30 +0100
            Re: making Debian secure by default Hans <hans.ullrich@loop.de> - 2024-03-28 16:50 +0100
              Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 19:20 +0100
                Re: making Debian secure by default Ralph Aichinger <ra@h5.or.at> - 2024-03-29 08:50 +0100
                Re: making Debian secure by default Stefan Monnier <monnier@iro.umontreal.ca> - 2024-03-29 20:10 +0100
                Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-03-29 20:40 +0100
            Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 17:00 +0100
              Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 21:20 +0100
            Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-28 18:50 +0100
              Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 20:40 +0100
              Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-29 18:00 +0100
                Re: making Debian secure by default Joe <joe@jretrading.com> - 2024-03-29 18:30 +0100
                  Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-29 18:50 +0100
                  Re: making Debian secure by default Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-04-01 02:30 +0200
                    Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-04-01 03:50 +0200
                      Re: making Debian secure by default Roberto C. Sánchez <roberto@debian.org> - 2024-04-01 05:00 +0200
                      Re: making Debian secure by default Nate Bargmann <n0nb@n0nb.us> - 2024-04-01 10:40 +0200
                        Re: making Debian secure by default <tomas@tuxteam.de> - 2024-04-06 09:50 +0200
                          Re: making Debian secure by default Nate Bargmann <n0nb@n0nb.us> - 2024-04-06 09:50 +0200
                            Re: making Debian secure by default <tomas@tuxteam.de> - 2024-04-06 09:51 +0200
                        Re: making Debian secure by default <tomas@tuxteam.de> - 2024-04-06 09:50 +0200
                        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-04-06 09:50 +0200
                        Re: making Debian secure by default Nate Bargmann <n0nb@n0nb.us> - 2024-04-06 09:51 +0200
                        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-04-06 09:51 +0200
                          Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-04-06 09:51 +0200
                          Re: making Debian secure by default Nate Bargmann <n0nb@n0nb.us> - 2024-04-06 09:52 +0200
                          Re: making Debian secure by default Charles Curley <charlescurley@charlescurley.com> - 2024-04-06 09:52 +0200
                        Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-04-06 09:51 +0200
                      Re: making Debian secure by default John Hasler <john@sugarbit.com> - 2024-04-06 09:51 +0200
                        Re: making Debian secure by default Joe <joe@jretrading.com> - 2024-04-06 09:52 +0200
                          Re: making Debian secure by default John Hasler <john@sugarbit.com> - 2024-04-06 09:52 +0200
                      Re: making Debian secure by default Joe <joe@jretrading.com> - 2024-04-06 09:52 +0200
                Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-29 18:50 +0100
                  Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-29 21:00 +0100
                    Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-30 17:10 +0100
            Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 19:10 +0100
              Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-03-28 23:20 +0100
      Re: making Debian secure by default Florent Rougon <f.rougon@free.fr> - 2024-03-28 17:30 +0100
        Re: making Debian secure by default Florent Rougon <f.rougon@free.fr> - 2024-03-28 18:10 +0100
        Re: making Debian secure by default Greg Wooledge <greg@wooledge.org> - 2024-03-28 18:10 +0100
          Re: making Debian secure by default Florent Rougon <f.rougon@free.fr> - 2024-03-28 18:10 +0100
    Re: making Debian secure by default jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-28 00:40 +0100
      Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 00:50 +0100
        Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 05:50 +0100
    Re: making Debian secure by default <tomas@tuxteam.de> - 2024-03-28 06:20 +0100
      Re: making Debian secure by default Emanuel Berg <incal@dataswamp.org> - 2024-03-28 06:30 +0100
        Re: making Debian secure by default <tomas@tuxteam.de> - 2024-03-28 08:20 +0100
        Re: making Debian secure by default Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-28 12:20 +0100
          Re: making Debian secure by default Emanuel Berg <incal@dataswamp.org> - 2024-03-28 12:40 +0100
            Re: making Debian secure by default David Wright <deblis@lionunicorn.co.uk> - 2024-03-28 21:40 +0100
              Re: making Debian secure by default Emanuel Berg <incal@dataswamp.org> - 2024-03-29 10:40 +0100
                Re: making Debian secure by default David Wright <deblis@lionunicorn.co.uk> - 2024-03-30 04:00 +0100
      Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-28 15:50 +0100
      Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 17:30 +0100
        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 18:10 +0100
          Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 21:50 +0100
        Re: making Debian secure by default tomas@tuxteam.de - 2024-03-28 18:30 +0100
          Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 20:30 +0100
            Re: making Debian secure by default Greg Wooledge <greg@wooledge.org> - 2024-03-28 20:30 +0100
              Re: making Debian secure by default Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-28 21:50 +0100
            Re: making Debian secure by default tomas@tuxteam.de - 2024-03-28 21:20 +0100
              Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-29 17:10 +0100
                Re: making Debian secure by default debian-user@howorth.org.uk - 2024-03-29 21:50 +0100
      Re: making Debian secure by default debian-user@howorth.org.uk - 2024-03-28 22:50 +0100
    Re: making Debian secure by default Marc SCHAEFER <schaefer@alphanet.ch> - 2024-03-28 12:10 +0100
      Re: making Debian secure by default Franco Martelli <martellif67@gmail.com> - 2024-03-28 17:30 +0100
      Re: making Debian secure by default Michel Verdier <mv524@free.fr> - 2024-03-28 17:30 +0100
        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 17:40 +0100
    Re: making Debian secure by default Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-28 21:50 +0100
    Re: making Debian secure by default Richmond <dnomhcir@gmx.com> - 2024-03-28 21:50 +0100
    Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-03-29 16:40 +0100
    Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-31 21:10 +0200
      Re: making Debian secure by default Roberto C. Sánchez <roberto@debian.org> - 2024-03-31 21:30 +0200
        Re: making Debian secure by default gene heskett <gheskett@shentel.net> - 2024-03-31 22:30 +0200
          Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-31 23:20 +0200
            Re: making Debian secure by default gene heskett <gheskett@shentel.net> - 2024-04-01 01:00 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#268679

[Multipart message — attachments visible in raw view] — view raw

* On 2024 31 Mar 20:46 -0500, Andy Smith wrote:
> In the xz case the further you go looking for a root cause the wider
> the implications are:
> 
> Q: Why was there a back door in sshd?
> A: Because some malicious code was linked to it.
> 
> Q: How did malicious code get linked to it?
> A: Its lzma dependency was compromised.

From what I have read, lzma is not a direct dependency of openssh.  It
turns out that it lzma is a dependency of libsystemd and that
relationship affected openssh.

Jacob Bachmeyer in analysis
(https://lists.gnu.org/archive/html/automake/2024-04/msg00000.html)
says:

Lastly on this topic, some of the blame for this needs to fall on the
systemd maintainers and their "katamari" architecture. There is no good
reason for notifications of daemon startup to pull in liblzma, but using
libsystemd for that purpose does exactly that, and ended up getting
xz-utils targeted as a means of getting to sshd without the OpenSSH
maintainers noticing.

End quote.

> Q: Who compromised the lzma dependency?
> A: One of the developers of that project who had full rights to
> commit code to it.
> 
> Q: Why did a persona that no one knows anything about get full
> access rights to a code repository that is linked to openssh?
> A: Because they did some work over a period of years that looked
> genuine and the single other developer who was overwhelmed with work
> decided to give them access based on that
> 
> Q: Why did lzma, a dependency of openssh, have a single overwhelmed
> developer?
> A: Because no one felt the need to pay a team of developers to work
> on it or audit work on it.

As Jacob notes, lzma is apparently not a direct dependency of openssh
which makes this story even more incredible.  Now we have to consider
the implications of patches to software that are related in non-obvious
ways.  Our systems are currently very complex and that complexity leads
to vulnerabilities in software that is not obviously linked.  Pretty
scary stuff, actually.

> Society demands that open source developers work, often for free,
> and that they merge contributions. If they push back and say they
> are unable to due to workload then they are encouraged to seek help
> by adding more committers. That's what apparently happened here: the
> attacker(s) seemingly counting on the pressure that would exist to
> give them rights within the project. It is hammered in to open
> source developers over and over:
> 
>     Allow others to contribute, or even to take over, if you are too
>     busy. It's the right thing to do.
> 
> We have now seen proof of what has long been theorised: that the
> above way of working is very vulnerable to attackers who are willing
> to put in some effort, and that "enough eyes make all bugs shallow"
> doesn't hold true unless the process is actually providing those
> eyes.

"Jai Tan" was somewhat patient at playing the long game it would appear.
The developer spent a lot of time and effort twisting the Autotools
build system into something that could hide the needed code.

You're absolutely correct, Andy, working its way deep into the project
while simultaneously planning to compromise it enabled the developer to
build a near disastrous back door.  It was also a very clever effort as
apparently the interaction of openssh, systemd and lzma were studied
carefully and understood to the level that choosing lzma as an attack
vector would likely go unnoticed as the relationship is apparently
non-obvious (though I've skimmed through the analysis my hobbyist coding
skills aren't up to the challenge of understanding this in its
entirety).

> I have no answers on how to fix such a deep-rooted societal problem
> but I am not going to start yelling obscenities at people on public
> mailing lists because they are wanting to discuss a CVE or whatever.

At the end of the day this is about trust.  The compromising developer
apparently set out from the start to exploit the trust of the main
maintainer and the overall community.  The sad part is, to me at least,
that the effort to analyze and understand the non-obvious relationship
of openssh, systemd, and lzma and then use that to create a back door
into openssh could have been used to improve security and create better
software.

Another hard lesson is that contributions are not always based on the
ideal of altruism that we in the "western world" hold dear.

BTW, I don't want to start a systemd bashing subthread, but I think it
bears some scrutiny give this latest event (disclaimer, yes I use
systemd as PID 1 on Debian Stable).

Finally, I am still involved with a project (hamlib) that is packaged in
many distributions.  I had to pull back several years ago and turn over
the day to day operations to a developer I came to trust.  For my own
part I became the administrator of the project after the original
developers had moved on and I was almost the most senior active
developer left.  Patches were backing up and someone needed to take
action so I did.

Your comments hit home as while I am content to continue to participate
in the Hamlib project on the limited basis that I do, at some point it
will need to be handed off to someone willing to take the reins.  This
recent event makes me just a little bit more skeptical about anyone
requesting to take over the project unless that person is a known member
of an already long established project.  Not an easy situation for
project maintainers and the community to fix.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#268685

[Multipart message — attachments visible in raw view] — view raw

On Mon, Apr 01, 2024 at 03:19:18PM -0500, Nate Bargmann wrote:
> * On 2024 01 Apr 14:01 -0500, Andy Smith wrote:

[...]

> Until now, who anticipated this?  I'm sure there are security
> researchers who have and it's likely that I'm not well-read enough on
> this topic to have seen it discussed.  How many people did it occur to
> that when A links to B and B links to C that C can create a
> vulnerability in A?  That is what I understand happened here.

This pattern has been seen in other contexts. Here [1] is a good review
of "supply chain attacks", which unsurprisingly happen most often in
decentrally managed package distributions which at the same time have
"production environments" where time-to-deploy is the main mover: npm,
PyPi and RubyGems. If you don't have the time to even consider what the
hundreds of packages you're ploughing into your app actually do, this
is no surprise.

So yes, the pattern was known. It was, up to now, pretty unusual in
this context. But the deeper "the stack" becomes... (so I think Nate
had a point. That Andy read that as a "systemd insult" is IMHO
infortunate, because it clogs a potentially useful discussion. But
there you are).

The next level is using a package phantasized by your trusty "AI" [2]
counsellor (and whose name was predicted by a malicious actor, because 
"AI" tends to phantasize names consistently). Note that this one was
just (yet?) a proof of concept.

Cheers

[1] https://arxiv.org/abs/2005.09535
[2] https://www.theregister.com/2024/03/28/ai_bots_hallucinate_software_packages/
-- 
tomás

[toc] | [prev] | [next] | [standalone]

#268703

[Multipart message — attachments visible in raw view] — view raw

* On 2024 01 Apr 23:41 -0500, tomas@tuxteam.de wrote:
> On Mon, Apr 01, 2024 at 03:19:18PM -0500, Nate Bargmann wrote:
> > * On 2024 01 Apr 14:01 -0500, Andy Smith wrote:
> 
> [...]
> 
> > Until now, who anticipated this?  I'm sure there are security
> > researchers who have and it's likely that I'm not well-read enough on
> > this topic to have seen it discussed.  How many people did it occur to
> > that when A links to B and B links to C that C can create a
> > vulnerability in A?  That is what I understand happened here.
> 
> This pattern has been seen in other contexts. Here [1] is a good review
> of "supply chain attacks", which unsurprisingly happen most often in
> decentrally managed package distributions which at the same time have
> "production environments" where time-to-deploy is the main mover: npm,
> PyPi and RubyGems. If you don't have the time to even consider what the
> hundreds of packages you're ploughing into your app actually do, this
> is no surprise.

If you have Rust and Go in mind, I am hugely skeptical of both, not
because of the languages themselves but because both, from what I see,
do not lend themselves easily to a set of known curated packages that
can be used for development.

Noted Debian developer Ian Jackson wrote a blog post back on 21 March
detailing the extra steps necessary to *only* use Debian Rust packages:

https://diziet.dreamwidth.org/18122.html

> So yes, the pattern was known. It was, up to now, pretty unusual in
> this context. But the deeper "the stack" becomes... (so I think Nate
> had a point. That Andy read that as a "systemd insult" is IMHO
> infortunate, because it clogs a potentially useful discussion. But
> there you are).

I think Andy was responding to Jacob Bachmeyer's use of "katamari" to
describe systemd/libsystemd which he uses again in:

https://lists.gnu.org/archive/html/automake/2024-04/msg00015.html

As far as I know, Jacob is not on this list so discussing his opinion is
a bit unfair to him.

> The next level is using a package phantasized by your trusty "AI" [2]
> counsellor (and whose name was predicted by a malicious actor, because 
> "AI" tends to phantasize names consistently). Note that this one was
> just (yet?) a proof of concept.

I am guessing that the Jia Tan actor(s) are watching the response to
this event carefully.  I doubt they have been deterred.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#268706

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 02, 2024 at 07:14:02AM -0500, Nate Bargmann wrote:
> * On 2024 01 Apr 23:41 -0500, tomas@tuxteam.de wrote:

[...]

> > This pattern has been seen in other contexts. Here [1] is a good review
> > of "supply chain attacks" [...]

> If you have Rust and Go in mind,

Absolutely not. On the contrary. I don't even think that the language
makes a difference in the risk of supply chain attack.

>                              I am hugely skeptical of both, not
> because of the languages themselves but because both, from what I see,
> do not lend themselves easily to a set of known curated packages that
> can be used for development.
> 
> Noted Debian developer Ian Jackson wrote a blog post back on 21 March
> detailing the extra steps necessary to *only* use Debian Rust packages:
> 
> https://diziet.dreamwidth.org/18122.html

No need to convince *me*.

> > So yes, the pattern was known. It was, up to now, pretty unusual in
> > this context. But the deeper "the stack" becomes... (so I think Nate
> > had a point. That Andy read that as a "systemd insult" is IMHO
> > infortunate, because it clogs a potentially useful discussion. But
> > there you are).
> 
> I think Andy was responding to Jacob Bachmeyer's use of "katamari" to
> describe systemd/libsystemd which he uses again in:

Yes, but he preferred to latch on "systemd", which is a pity, because
the "katamari" part does have a point.

> > The next level is using a package phantasized by your trusty "AI" [2]
> > counsellor (and whose name was predicted by a malicious actor, because 
> > "AI" tends to phantasize names consistently). Note that this one was
> > just (yet?) a proof of concept.
> 
> I am guessing that the Jia Tan actor(s) are watching the response to
> this event carefully.  I doubt they have been deterred.

We don't know much about Jia Tan (and we might never know). To me, one
possible branch is the one most being talked about, that it was a
state-level actor (group) planning things for two years from the start.

More plausible to me would be a bona fide contributor who at some point
was picked up and turned bad (by bribery or coercion). That's more the
modus operandi of such actors [1]. To be honest, this one is also more
unsettling to me.

Cheers

[1] Remember Bruce Schneier's observation that the NSA is better at
   breaking knuckles than at breaking code?
-- 
t

[toc] | [prev] | [next] | [standalone]

#268693

[Multipart message — attachments visible in raw view] — view raw

On Mon, Apr 01, 2024 at 07:00:29PM +0000, Andy Smith wrote:
> Hi,
> 
> On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote:
> > From what I have read, lzma is not a direct dependency of openssh.  It
> > turns out that it lzma is a dependency of libsystemd and that
> > relationship affected openssh.
> > 
> > Jacob Bachmeyer in analysis
> > (https://lists.gnu.org/archive/html/automake/2024-04/msg00000.html)
> > says:
> > 
> > Lastly on this topic, some of the blame for this needs to fall on the
> > systemd maintainers [...]

> In my view a great example of the "people other than me just need to
> get good" fallacy merged with the group of people predisposed to
> hate systemd.

[...]

Please, don't make this into a systemd flamefest. W've had our share
of this already.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#268702

Hi,

On Mon, Apr 01, 2024 at 03:19:18PM -0500, Nate Bargmann wrote:
> I've no idea of Jacob Bachmeyer's bias toward systemd, if any,
> other than "katamari" apparently refers to a Japanese video game I
> know absolutely nothing about.

I also don't know anything of Bachmeyer and very little of Katamari
Damacy, but I know enough to see that it was a pejorative
description: Katamari Damacy is a game about a huge ball that
agglomerates everything in the environment that it touches.

I think the point about the industry needing to find ways to strip
down, audit and sandbox dependencies could have been made without
attacking systemd, because there is a whole group of people whose
mental processes will stop at that point, having found an agreeable
bandwagon to jump on. The nuance that the systemd project started
doing that, and before this even was a wider known issue, is totally
lost.

Thanks,
Andy


-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#268710

[Multipart message — attachments visible in raw view] — view raw

* On 2024 01 Apr 14:01 -0500, Andy Smith wrote:
> Hi,
> 
> On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote:
> > From what I have read, lzma is not a direct dependency of openssh.  It
> > turns out that it lzma is a dependency of libsystemd and that
> > relationship affected openssh.
> > 
> > Jacob Bachmeyer in analysis
> > (https://lists.gnu.org/archive/html/automake/2024-04/msg00000.html)
> > says:
> > 
> > Lastly on this topic, some of the blame for this needs to fall on the
> > systemd maintainers and their "katamari" architecture. There is no good
> > reason for notifications of daemon startup to pull in liblzma, but using
> > libsystemd for that purpose does exactly that, and ended up getting
> > xz-utils targeted as a means of getting to sshd without the OpenSSH
> > maintainers noticing.
> > 
> > End quote.
> 
> In my view a great example of the "people other than me just need to
> get good" fallacy merged with the group of people predisposed to
> hate systemd.

AIUI, systemd already has patches to limit the use of lzma to only
dlopen when needed: https://lwn.net/Articles/967399/

This action apparently predates this incident and was made for other
considerations.  More than anything, I think this shows in the future
some hard decisions will need to made to prevent unrelated code
affecting other code through linked intermediate code.  AIUI, that would
be a fundamental change to our systems that would likely break
(assuming) a lot of software.

> It could have been any direct or indirect dependency of sshd here.

Or any other daemon but openssh is a very attractive target and systemd
as a service manager is a defacto standard.

> I'm quite sure almost none of them have the required resources and
> processes to detect something like this.

Until now, who anticipated this?  I'm sure there are security
researchers who have and it's likely that I'm not well-read enough on
this topic to have seen it discussed.  How many people did it occur to
that when A links to B and B links to C that C can create a
vulnerability in A?  That is what I understand happened here.

The social part where Jia Tan (individual, group, state actor?) gains
commit privileges, which in a small project are seldom reviewed as some
level of trust has been established before granting such privileges, and
over time begins the process of introducing compromising code bit by
bit.  It is curious that any of the compromise was committed when other
parts were added at the creation of the release tarball.  Perhaps it was
determined that a two-prong approach would garner less suspicion.  I
have also read that this entity began a campaign to get the latest lzma
release into distributions quickly.  That kind of behavior will now
raise suspicions due to this event.  When a developer believes that
distributions should update ASAP they likely better have a CVE issue at
hand or expect their work to be more carefully audited.

> I think anyone buying into systemd-blaming here needs to have a good
> hard look at their biases. Which is another part of this massive
> social problem. It's such a distraction. And here we are in a thread
> that started with a bug in a 30+ year old setgid binary.

We all carry biases.  I've no idea of Jacob Bachmeyer's bias toward
systemd, if any, other than "katamari" apparently refers to a Japanese
video game I know absolutely nothing about. How that relates, good or
bad, I have no idea.  I will say that I have been satisfied with its
implementation over several Debian releases but that is because I trust
Debian more than upstream.

Upstream systemd has not done itself many favors over the years WRT
community interaction.  I think that developers would be wise not to
follow the systemd project's path with their own endeavors.  I do find
systemd useful and even enable some of the optional features on my
Debian systems.  It works well enough and the commonality of
configuration style between the optional components is helpful.

Unavoidably, systemd is going to get a bit of bad press here simply
because of its service manager role that enabled the C creating a
vulnerability in A scenario.  The upshot is that patches to
openssh-portable applied by Debian might move away from linking in
libsystemd if I read that LWN thread correctly.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#268715

Hi,

On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote:
> From what I have read, lzma is not a direct dependency of openssh.  It
> turns out that it lzma is a dependency of libsystemd and that
> relationship affected openssh.
> 
> Jacob Bachmeyer in analysis
> (https://lists.gnu.org/archive/html/automake/2024-04/msg00000.html)
> says:
> 
> Lastly on this topic, some of the blame for this needs to fall on the
> systemd maintainers and their "katamari" architecture. There is no good
> reason for notifications of daemon startup to pull in liblzma, but using
> libsystemd for that purpose does exactly that, and ended up getting
> xz-utils targeted as a means of getting to sshd without the OpenSSH
> maintainers noticing.
> 
> End quote.

In my view a great example of the "people other than me just need to
get good" fallacy merged with the group of people predisposed to
hate systemd.

It could have been any direct or indirect dependency of sshd here.
I'm quite sure almost none of them have the required resources and
processes to detect something like this.

I think anyone buying into systemd-blaming here needs to have a good
hard look at their biases. Which is another part of this massive
social problem. It's such a distraction. And here we are in a thread
that started with a bug in a 30+ year old setgid binary.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#268716

On Mon, Apr 1, 2024 at 5:55 PM Charles Curley
<charlescurley@charlescurley.com> wrote:
>
> On Mon, 1 Apr 2024 19:00:29 +0000
> Andy Smith <andy@strugglers.net> wrote:
>
> > In my view a great example of the "people other than me just need to
> > get good" fallacy merged with the group of people predisposed to
> > hate systemd.
> >
> > It could have been any direct or indirect dependency of sshd here.
> > I'm quite sure almost none of them have the required resources and
> > processes to detect something like this.
>
> Easy, now. No-one is attacking systemd, and I don't think anyone wanted
> to start a systemd war. This could also have happened under System V
> initialization.
>
> I have no doubt that this sort of thing has happened in the past, and I
> fully expect it will happen again in the future. However, the defect
> has been caught and repaired. The system for dealing with
> vulnerabilities is working, if not perfectly. The question now is: what
> lessons can we learn from it.

++.

Right now, Linux does not have a classification system to identify
critical projects, or help with resources for those projects. I don't
like using the word "Linux", but I don't know how to describe the
ecosystem.

For critical projects, I'm talking about the cURL, OpenSSL's OpenSSH,
Wget's and Xz's of the world. These are critical to a base Linux
system. When they have a memory bug or a CVE, action needs to be
taken. The free software world does not even know what the list is.
(And I'm not talking about the other useless fodder that shows up in
repos).

Other vulnerable projects include ncurses and libnettle. Ncurses is
run by Thomas Dickey (https://invisible-island.net/). libnettle is run
by Niels Möller (https://www.lysator.liu.se/~nisse/nettle/). Both are
one-man shows with no continuity plans. Dickey does not even run a
public version control system. You have to download his release
tarballs. There's nothing to make pull requests against. If DIckey or
Möller got hit by a bus crossing the street, there would be problems
for years.

Selling support for critical projects does not seem to work. I seem to
recall Werner Koch of GnuPG roughing it when relying on support
contracts to fund a project.

So one of the first steps would be to identify critical projects,
shore up their governance, and then help the project with additional
resources, like a grant and trusted eyeballs.

Jeff

[toc] | [prev] | [next] | [standalone]

#268734

[Multipart message — attachments visible in raw view] — view raw

* On 2024 01 Apr 16:55 -0500, Charles Curley wrote:
> On Mon, 1 Apr 2024 19:00:29 +0000
> Andy Smith <andy@strugglers.net> wrote:
> 
> > In my view a great example of the "people other than me just need to
> > get good" fallacy merged with the group of people predisposed to
> > hate systemd.
> > 
> > It could have been any direct or indirect dependency of sshd here.
> > I'm quite sure almost none of them have the required resources and
> > processes to detect something like this.
> 
> Easy, now. No-one is attacking systemd, and I don't think anyone wanted
> to start a systemd war. This could also have happened under System V
> initialization.

AIUI (please correct me if I am in error), any dependency chain that
then depends on something else could create a vulnerability.  I am
rather surprised to see that openssh-server has so many dependencies:

Depends: adduser, libpam-modules, libpam-runtime, lsb-base,
openssh-client (= 1:9.2p1-2+deb12u2), openssh-sftp-server, procps, ucf,
debconf (>= 0.5) | debconf-2.0, runit-helper (>= 2.14.0~), libaudit1 (>=
1:2.2.1), libc6 (>= 2.36), libcom-err2 (>= 1.43.9), libcrypt1 (>=
1:4.1.0), libgssapi-krb5-2 (>= 1.17), libkrb5-3 (>= 1.13~alpha1+dfsg),
libpam0g (>= 0.99.7.1), libselinux1 (>= 3.1~), libssl3 (>= 3.0.11),
libsystemd0, libwrap0 (>= 7.6-4~), zlib1g (>= 1:1.1.4)

Not all are libraries, but if IUC, libc6 shows to depend on libgcc-s1,
so if that library could be compromised, then openssh-server could be
vulnerable.  It's quite possible that I am wrong (hopefully) or we have
an even more massive problem.

> I have no doubt that this sort of thing has happened in the past, and I
> fully expect it will happen again in the future. However, the defect
> has been caught and repaired. The system for dealing with
> vulnerabilities is working, if not perfectly. The question now is: what
> lessons can we learn from it.

From what I am seeing right now discussions are centering around
comparing the file list associated with a VCS tag and a release tarball,
and somehow verifying the identity of contributors/committers.  I'm sure
other ideas are being discussed that I've not read.  Suffice it to say,
at the moment this is not being swept under the proverbial rug.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#268742

On Mon, 1 Apr 2024 19:00:29 +0000
Andy Smith <andy@strugglers.net> wrote:

> In my view a great example of the "people other than me just need to
> get good" fallacy merged with the group of people predisposed to
> hate systemd.
> 
> It could have been any direct or indirect dependency of sshd here.
> I'm quite sure almost none of them have the required resources and
> processes to detect something like this.

Easy, now. No-one is attacking systemd, and I don't think anyone wanted
to start a systemd war. This could also have happened under System V
initialization.

I have no doubt that this sort of thing has happened in the past, and I
fully expect it will happen again in the future. However, the defect
has been caught and repaired. The system for dealing with
vulnerabilities is working, if not perfectly. The question now is: what
lessons can we learn from it.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#268717

On Mon, Apr 1, 2024 at 4:34 AM Nate Bargmann <n0nb@n0nb.us> wrote:
>
> * On 2024 31 Mar 20:46 -0500, Andy Smith wrote:
> > In the xz case the further you go looking for a root cause the wider
> > the implications are:
> >
> > Q: Why was there a back door in sshd?
> > A: Because some malicious code was linked to it.
> >
> > Q: How did malicious code get linked to it?
> > A: Its lzma dependency was compromised.
>
> From what I have read, lzma is not a direct dependency of openssh.  It
> turns out that it lzma is a dependency of libsystemd and that
> relationship affected openssh.
>
> Jacob Bachmeyer in analysis
> (https://lists.gnu.org/archive/html/automake/2024-04/msg00000.html)
> says:
>
> Lastly on this topic, some of the blame for this needs to fall on the
> systemd maintainers and their "katamari" architecture. There is no good
> reason for notifications of daemon startup to pull in liblzma, but using
> libsystemd for that purpose does exactly that, and ended up getting
> xz-utils targeted as a means of getting to sshd without the OpenSSH
> maintainers noticing.
>
> End quote.

It looks like SELinux is a larger problem than Systemd:
<https://www.openwall.com/lists/oss-security/2024/03/31/9>. Systemd
already dropped the liblzma dependency, but they did it for a smaller
initram image, and not to reduce attack surface.

Jeff

[toc] | [prev] | [next] | [standalone]

#268720

Joe writes:
> I think this was amply demonstrated by Heartbleed, where the offending
> code was examined by *one* other pair of eyes, before approval was
> granted for inclusion in OpenSSL.

The "many eyes" phase comes after release.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#268732

On Mon, 01 Apr 2024 13:50:22 -0500
John Hasler <john@sugarbit.com> wrote:

> Joe writes:
> > I think this was amply demonstrated by Heartbleed, where the
> > offending code was examined by *one* other pair of eyes, before
> > approval was granted for inclusion in OpenSSL.  
> 
> The "many eyes" phase comes after release.

Which didn't happen, at least not for two years.

I would suggest that for any software as critical as OpenSSL, more than
one pair of eyes would have been appropriate *before* release.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#268746

Joe writes:
> Which didn't happen, at least not for two years.

It happened eventually, which is my point.

> I would suggest that for any software as critical as OpenSSL, more
> than one pair of eyes would have been appropriate *before* release.

I would suggest that critical projects such as OpenSSL need to practice
a form of "dependecy management" analogous to "supply chain management":
track dependency chains and periodically re-qualify each level.  A full
audit might not be possible but at least look closely enough to notice
when a library is being supported by one overworked guy who is taking
patches from random strangers.

NOTE: this is just a suggestion.  I don't claim to be any sort of
security expert  nor am I trying to tell anyone what to do.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#268755

On Mon, 1 Apr 2024 01:45:07 +0000
Andy Smith <andy@strugglers.net> wrote:


>  "enough eyes make all bugs shallow"
> doesn't hold true unless the process is actually providing those
> eyes.
> 

I think this was amply demonstrated by Heartbleed, where the offending
code was examined by *one* other pair of eyes, before approval was
granted for inclusion in OpenSSL.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#268624

On 2024-03-29, Andy Smith <andy@strugglers.net> wrote:
>> 
>> It makes no fucking difference, because your important data is elsewhere
>> and completely out of your control.
>
> I WAS going to gently suggest that you have a lie down in a cool,
> shaded room, but which of us had this on our 2024 bingo card?
>

This is not a rational response or argument to the reality of the
situation. You are not in control of your essential data if you are
integrated into modern society. I have demonstrated my point with the
French health-care system. If you have a counter-argument, I'd love to
hear it. But you manifestly do not, and resort childish retorts that
mean nothing.

[toc] | [prev] | [next] | [standalone]

#268631

Hi,

On Fri, Mar 29, 2024 at 05:43:22PM -0000, Curt wrote:
> On 2024-03-29, Andy Smith <andy@strugglers.net> wrote:
> >> 
> >> It makes no fucking difference, because your important data is elsewhere
> >> and completely out of your control.
> >
> > I WAS going to gently suggest that you have a lie down in a cool,
> > shaded room, but which of us had this on our 2024 bingo card?
> 
> This is not a rational response or argument to the reality of the
> situation. You are not in control of your essential data if you are
> integrated into modern society. I have demonstrated my point with the
> French health-care system. If you have a counter-argument, I'd love to
> hear it. But you manifestly do not, and resort childish retorts that
> mean nothing.

I wasn't trying to bait you in any way. The above was what I thought
was a light-hearted way to say that I genuinely think you need to
relax a little about things that are outside of your control. I'm
sorry it wasn't taken that way and I get that you don't share that
view.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#268641

On 2024-03-29, Andy Smith <andy@strugglers.net> wrote:

> I wasn't trying to bait you in any way. The above was what I thought
> was a light-hearted way to say that I genuinely think you need to
> relax a little about things that are outside of your control. I'm
> sorry it wasn't taken that way and I get that you don't share that
> view.

I admit I missed the subtly light-hearted tone of your remarks. But the
people here in general are the exact equivalent of the senile: they
repeat the same weary stories over and over again as if they were
forever new, and we'd not heard them numerous times before. There's
always someone in these discussions who, having accepted the current
estimate of the age of the universe, then asserts that it will require
twice that period to crack this or that password. The incontrovertible
evidence that this is irrelevant to the price of tea in China is
infrequently noted. So I noted it and gave a recent example of its
complete irrelevancy. The ruffled feathers of you old birds serves, at
least, as a modicum of comic relief.

> Thanks,


> Andy
>


-- 

[toc] | [prev] | [next] | [standalone]

#268597

On Thu, Mar 28, 2024 at 11:24 AM Greg Wooledge  wrote:
>
> On Thu, Mar 28, 2024 at 01:30:32PM +0000, Andy Smith wrote:
> > I'm just not sure that you'll find any "hardening" guide that will
> > specifically say "disable writing to your terminal as there might be
> > a bug in a binary that is setgid tty" before yesterday's reveal that
> > there is such a bug in "wall".
> >
> > The more general advice to audit every setuid/setgid binary is more
> > likely to be present.
> [...]
> > If the maintainer of util-linux doesn't agree, then the next thing
> > I'd try is a bug against the Debian Administrator's Handbook:
> >
> >     https://www.debian.org/doc/manuals/debian-handbook/
> >
> > This has a chapter on security, so possibly it would be appropriate
> > to mention "m,esg n" there.
>
> A more proactive endeavor would be to document known best practices
> on the wiki.  A quick search found a couple pages that might serve
> as starting points:
>
>     https://wiki.debian.org/SecurityManagement
>     https://wiki.debian.org/Hardening  -- says it's for package maintainers
>
> Anyone who is serious about such a project probably has a long road ahead
> of them.

Is there a generally preferred web link checker program for Debian?
I took a look at
  https://www.debian.org/doc/manuals/securing-debian-manual/ch04s15.en.html
and the 4.15. Protecting against buffer overflows section has this bit:
recompile the source code to introduce proper checks that prevent
overflows, using the
 http://www.research.ibm.com/trl/projects/security/ssp/ patch for GCC
(which is used by
 http://www.adamantix.org)

http://www.research.ibm.com/trl/projects/security/ssp/ patch gives me
a connect failed and
http://www.adamantix.org sends me to a vietnamese tv site??

Seems to me that an easy first step would be to check that all the
links still work.

Regards,
Lee

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web