Re: making Debian secure by default

[tomas]

On Tue, Apr 02, 2024 at 07:14:02AM -0500, Nate Bargmann wrote:
> * On 2024 01 Apr 23:41 -0500, to...@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


signature.asc
Description: PGP signature

Re: making Debian secure by default

[Nate Bargmann]

* On 2024 01 Apr 23:41 -0500, to...@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



signature.asc
Description: PGP signature

Re: making Debian secure by default

[DdB]

Am 27.03.2024 um 22:30 schrieb Lee:
> oof.  Are there instructions somewhere on how to make Debian secure by 
> default?

To be honest: I did not read this thread, as my spidey senses got
tingling. IMHO Even the idea/concept, that such a thing would be
possible, is broken.

Sounds like: Get me a car, that never kills anybody, no matter how
stupid the driver is... (impossible).

But to slow it down a bit:
As a former software engeneer, i learned quite a few things, among the
important ones were the lessons around "Cleanliness" (donno, if this
word even exists).

>From time to time, even experienced devs come across a choice:
Either, they work on very clean contracts between software parts, which
in an ideal world lead to good interfaces, but this makes some difficult
tasks impossible, as it may be impossible to agree upon such a contract
with everyone involved (or the whole world).
Or, they lean more towards what is feasible, preferring tricking or
evading from contracts, like what most hackers do.
My own recipe in such cases, was to feel my inner work ethic and to
trust it more than anything. But i do understand, that such a solution
is bound to be changing and thus is not really a good solution in general.

But that leaves us with:
There is no way, a secure system will ever come to be. We need to take
responsability for what we are doing, as even a hammer can be used to
kill. Sorry, that means we have to use our brains, learn from mistakes
and do the best we can without falling asleep.

Just my 2 cents
DdB

Re: making Debian secure by default

[tomas]

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


signature.asc
Description: PGP signature

Re: making Debian secure by default

[tomas]

On Mon, Apr 01, 2024 at 07:00:29PM +, 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/msg0.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


signature.asc
Description: PGP signature

Re: making Debian secure by default

[Nate Bargmann]

* On 2024 01 Apr 16:55 -0500, Charles Curley wrote:
> On Mon, 1 Apr 2024 19:00:29 +
> Andy Smith  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



signature.asc
Description: PGP signature

Re: making Debian secure by default

[Jeffrey Walton]

On Mon, Apr 1, 2024 at 5:55 PM Charles Curley
 wrote:
>
> On Mon, 1 Apr 2024 19:00:29 +
> Andy Smith  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

Re: making Debian secure by default

[Charles Curley]

On Mon, 1 Apr 2024 19:00:29 +
Andy Smith  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/

Re: making Debian secure by default

[Andy Smith]

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

Re: making Debian secure by default

[Nate Bargmann]

* 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/msg0.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



signature.asc
Description: PGP signature

Re: making Debian secure by default

[John Hasler]

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 
j...@sugarbit.com
Elmwood, WI USA

Re: making Debian secure by default

[Joe]

On Mon, 01 Apr 2024 13:50:22 -0500
John Hasler  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

Re: making Debian secure by default

[Andy Smith]

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/msg0.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

Re: making Debian secure by default

[John Hasler]

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 
j...@sugarbit.com
Elmwood, WI USA

Re: making Debian secure by default

[Joe]

On Mon, 1 Apr 2024 01:45:07 +
Andy Smith  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

Re: making Debian secure by default

[Jeffrey Walton]

On Mon, Apr 1, 2024 at 4:34 AM Nate Bargmann  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/msg0.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:
. Systemd
already dropped the liblzma dependency, but they did it for a smaller
initram image, and not to reduce attack surface.

Jeff

Re: making Debian secure by default

[Nate Bargmann]

* 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/msg0.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 

Re: making Debian secure by default

[Roberto C . Sánchez]

On Mon, Apr 01, 2024 at 01:45:07AM +, Andy Smith wrote:
> Hi,
> 
> On Sun, Mar 31, 2024 at 07:19:41PM -0500, Nicholas Geovanis wrote:
> > I would think A Smith's comment here was directed to this interesting bit
> > from the report he cited:
> > 
> > Given the activity over several weeks, the committer is either directly
> > involved or there was some quite severe compromise of their
> > system. Unfortunately the latter looks like the less likely explanation,
> > given
> > they communicated on various lists about the "fixes" mentioned above.
> > 
> > End quote.
> 
> I don't really want to go much further into this as the person I
> responded to was clearly further upset by what I said, but all I was
> suggesting was not getting too worked up about things that are so
> far out of one's control.
> 
> To bring this sort of thing somewhat more under humanity's control
> is going to take some very large scale reworking of how the open
> source software supply chain works, possibly even how society works.
> It's not something that can be achieved by an end user with a best
> practices document or a security checklist. Unless step one on the
> list is "give up general purpose computing."
> 
> 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.
> 
> 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.
> 

I love this. It's a great example of the "5 whys" (I know one of the 5
here was technically a "how", but could have just as easily been
rephrased as a "why").

The final answer isn't comforting, but it certainly provides a clear and
actionable path: "ensure critical projects aren't understaffed."

It seems like an extremely obvious thing, the sort of thing that we
wouldn't let happen. But then this XKCD from a year or two ago wouldn't
be such an accurate representation of so many projects:
https://xkcd.com/2347/

(I'm sure it's probably been linked in a 1,000 different threads in a
1,000 different forums related to this problem by now.)

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: making Debian secure by default

[Andy Smith]

Hi,

On Sun, Mar 31, 2024 at 07:19:41PM -0500, Nicholas Geovanis wrote:
> I would think A Smith's comment here was directed to this interesting bit
> from the report he cited:
> 
> Given the activity over several weeks, the committer is either directly
> involved or there was some quite severe compromise of their
> system. Unfortunately the latter looks like the less likely explanation,
> given
> they communicated on various lists about the "fixes" mentioned above.
> 
> End quote.

I don't really want to go much further into this as the person I
responded to was clearly further upset by what I said, but all I was
suggesting was not getting too worked up about things that are so
far out of one's control.

To bring this sort of thing somewhat more under humanity's control
is going to take some very large scale reworking of how the open
source software supply chain works, possibly even how society works.
It's not something that can be achieved by an end user with a best
practices document or a security checklist. Unless step one on the
list is "give up general purpose computing."

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.

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.

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.

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.

Thanks,
Andy

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

Re: making Debian secure by default

[Nicholas Geovanis]

On Fri, Mar 29, 2024, 12:24 PM Joe  wrote:

> On Fri, 29 Mar 2024 16:53:04 +
> Andy Smith  wrote:
>
> > Hello,
> >
> > On Thu, Mar 28, 2024 at 05:47:44PM -, Curt wrote:
> > > On 2024-03-28, Greg Wooledge  wrote:
> > > >
> > > > A more proactive endeavor would be to document known best
> > > > practices
> > >
> > > 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?
> >
> > https://www.openwall.com/lists/oss-security/2024/03/29/4
> >
> > (Upstream xz/lzma project compromised, hostile code inserted into
> > sshd in Debian sid and other leading edge distros.)
> >
>
> Hah! Most of us remember Heartbleed.
>
> He's actually referring to credentials stored externally being
> compromised. I'm not sure what can be done about that: maybe make some
>

I would think A Smith's comment here was directed to this interesting bit
from the report he cited:

Given the activity over several weeks, the committer is either directly
involved or there was some quite severe compromise of their
system. Unfortunately the latter looks like the less likely explanation,
given
they communicated on various lists about the "fixes" mentioned above.

End quote. The issue appears to be a bad actor masquerading as (or being)
the real maintainer. There's no software-development or identity management
solution to that, it has to be organizational. We're lucky to have software
guys as sharp the one who caught this.

kind of, you know, law, about storing sensitive data, and prosecuting
> people who are responsible for failure to keep it secure... nothing
> like accountability for discouraging negligence.
>
> --
> Joe
>
>

Re: making Debian secure by default

[gene heskett]

On 3/31/24 17:16, Andy Smith wrote:

Hello,

On Sun, Mar 31, 2024 at 04:27:52PM -0400, gene heskett wrote:

On 3/31/24 15:26, Roberto C. Sánchez wrote:

https://lists.debian.org/debian-security-announce/2024/msg00058.html

Does this mean its now safe to update our bookworm installs?


I am not aware of a time when it was not safe to do so, since the
ext4 corruption bug of December 2023.

What were you thinking of?


Just trying to clarify Andy.  Thatk you


Thanks,
Andy



Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: making Debian secure by default

[Andy Smith]

Hello,

On Sun, Mar 31, 2024 at 04:27:52PM -0400, gene heskett wrote:
> On 3/31/24 15:26, Roberto C. Sánchez wrote:
> > https://lists.debian.org/debian-security-announce/2024/msg00058.html
> Does this mean its now safe to update our bookworm installs?

I am not aware of a time when it was not safe to do so, since the
ext4 corruption bug of December 2023.

What were you thinking of?

Thanks,
Andy

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

Re: making Debian secure by default

[gene heskett]

On 3/31/24 15:26, Roberto C. Sánchez wrote:

On Sun, Mar 31, 2024 at 07:00:50PM +, Andy Smith wrote:

Hello,

On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:

I just saw this advisory
   Escape sequence injection in util-linux wall (CVE-2024-28085)
 https://seclists.org/fulldisclosure/2024/Mar/35
where they're talking about grabbing other users sudo password.


I note that "write" and "wall" in Debian had setgid removed after this.

 
https://salsa.debian.org/debian/util-linux/-/commit/c4be137b4b09a855713c1f4d052dfee773c4ad3b
 
https://metadata.ftp-master.debian.org/changelogs//main/u/util-linux/util-linux_2.39.3-11_changelog


The fix has also been made to stable and oldstable:
https://lists.debian.org/debian-security-announce/2024/msg00058.html

Does this mean its now safe to update our bookworm installs?
TY.


Regards,

-Roberto


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: making Debian secure by default

[Roberto C . Sánchez]

On Sun, Mar 31, 2024 at 07:00:50PM +, Andy Smith wrote:
> Hello,
> 
> On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> > I just saw this advisory
> >   Escape sequence injection in util-linux wall (CVE-2024-28085)
> > https://seclists.org/fulldisclosure/2024/Mar/35
> > where they're talking about grabbing other users sudo password.
> 
> I note that "write" and "wall" in Debian had setgid removed after this.
> 
> 
> https://salsa.debian.org/debian/util-linux/-/commit/c4be137b4b09a855713c1f4d052dfee773c4ad3b
> 
> https://metadata.ftp-master.debian.org/changelogs//main/u/util-linux/util-linux_2.39.3-11_changelog
> 
The fix has also been made to stable and oldstable:
https://lists.debian.org/debian-security-announce/2024/msg00058.html

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: making Debian secure by default

[Andy Smith]

Hello,

On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> I just saw this advisory
>   Escape sequence injection in util-linux wall (CVE-2024-28085)
> https://seclists.org/fulldisclosure/2024/Mar/35
> where they're talking about grabbing other users sudo password.

I note that "write" and "wall" in Debian had setgid removed after this.


https://salsa.debian.org/debian/util-linux/-/commit/c4be137b4b09a855713c1f4d052dfee773c4ad3b

https://metadata.ftp-master.debian.org/changelogs//main/u/util-linux/util-linux_2.39.3-11_changelog

Thanks,
Andy

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

Re: making Debian secure by default

[Curt]

On 2024-03-29, Andy Smith  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
>


-- 

Re: making Debian secure by default

[Marc SCHAEFER]

Hello,

On Fri, Mar 29, 2024 at 07:02:54PM +0100, Kamil Jo?ca wrote:
> O-o, is there any simple test to check if I have infected version or
> not?

For example, under root:

  path="$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')"
   if hexdump -ve '1/1 "%.2x"' "$path" | grep -q  
f30f1efa554889f54c89ce5389fb81e700804883ec28488954241848894c2410
   then
echo probably vulnerable
   else
echo probably not vulnerable
   fi

NB: always think and read before typing root commands, or any commands
you find on a forum or mailing-list :)

More info:
   https://boehs.org/node/everything-i-know-about-the-xz-backdoor
  Interesting read about social interactions

   https://www.openwall.com/lists/oss-security/2024/03/29/4
  ref for the code above

   https://www.openwall.com/lists/oss-security/2024/03/29/23
  idea to confine the sshd -> systemd dependancy,
  in a specific process, because of the huge systemd
  attack surface

Re: making Debian secure by default

[David Wright]

On Fri 29 Mar 2024 at 10:31:09 (+0100), Emanuel Berg wrote:
> David Wright wrote:
> 
> >> Ah, surely it can't refer to that as that would be
> >> completely ridiculous as it would imply "wanna install
> >> stuff? sure, but then it isn't secure anymore".
> >
> > It's not clear what "isn't secure anymore" means. [...]
> 
> It means as soon as you start doing stuff with the software,
> it isn't secure anymore.

As you wrote. But software isn't just "secure" or "not secure",
all or nothing. Security, in any aspect of life, is gradational.

> Which is comical to some extent as
> doing stuff is the purpose of computers.
> 
> So to base security boasting on people having the most
> minimal, restricted and inactive system, it is like boasting
> this marvelous piece of body armor is guaranteed to not have
> a single infantryman killed - just don't go to war.

You don't expect people working at HQ to get shot or blown up,
but that is a more likely fate for those fighting at the front.
As well as variations with seniority and physical position,
there will be temporal variations, just like in civilian life,
1 through 5 or green through red etc.

> (Note that now I'm just making fun at the slogan and boasting,
> not saying anything negative of their OS necessarily - I've
> used it myself, it send pretty good and, indeed, secure.)
> 
> >  "Secure by Default"
> >
> >  "To ensure that novice users of OpenBSD do not need to
> >   become security experts overnight (a viewpoint which other
> >   vendors seem to have), we ship the operating system in
> >   a Secure by Default mode. All non-essential services are
> >   disabled. As the user/administrator becomes more familiar
> >   with the system, he will discover that he has to enable
> >   daemons and other parts of the system. During the process
> >   of learning how to enable a new service, the novice is
> >   more likely to learn of security considerations."
> >
> > from https://www.openbsd.org/security.html
> > OTOH:
> >
> >  "There are many applications one might want to use on an
> >   OpenBSD system. To make this software easier to install
> >   and manage, it is ported to OpenBSD and packaged. The aim
> >   of the package system is to keep track of which software
> >   gets installed, so that it may be easily updated or
> >   removed. In minutes, a large number of packages can be
> >   fetched and installed, with everything put in the
> >   right place."
> >
> >  "The ports collection does not go through the same thorough
> >   security audit that is performed on the OpenBSD base
> >   system. Although we strive to keep the quality of the
> >   packages high, we just do not have enough resources to
> >   ensure the same level of robustness and security."
> >
> > from https://www.openbsd.org/faq/faq15.html (Package
> > Management).
> 
> The more you install, the less secure it gets. Yeah, can't
> base the security model on that.

Not a base; it's just inevitable, both in software and life.
You're increasing your attack surface as you install and use
more software, just like driving, visiting bars, attending
concerts, or going on foreign or adventure holidays.

> They should do it the other way around, write a piece of
> software that breaks everything. Install in on OpenBSD and if
> it breakes it, OpenBSD is not more secure than anyone else.
> If nothing happens tho most likekly you are safe.

I don't know about OpenBSD specifically, but in general it's
already done, by such methods as exposing software to malicious
and random inputs, corner cases, and so on. That doesn't have
to mean it's done /instead of/ auditing.

Cheers,
David.

Re: making Debian secure by default

[debian-user]

Curt  wrote:
> On 2024-03-28, to...@tuxteam.de  wrote:
> >
> > Security, as Bruce Schneier [1] says, is a process. Not a product. 
> 
> A process that is essentially out of your control.

I would hope it is, given how little I or most people understand about
security.

> This is the elephant in the room that you do not wish to address.

There's no such elephant since most people understand it well, and
just live with it. As we live with not being in control of our
governments, or financial institutions, or (here in the UK) building
control or post office or ... (there are lots more examples)

> Anyway, dream on.

Re: making Debian secure by default

[Andy Smith]

Hello,

On Fri, Mar 29, 2024 at 07:02:54PM +0100, Kamil Jońca wrote:
> Andy Smith  writes:
> > https://www.openwall.com/lists/oss-security/2024/03/29/4
> >
> > (Upstream xz/lzma project compromised, hostile code inserted into
> > sshd in Debian sid and other leading edge distros.)
> 
> O-o, is there any simple test to check if I have infected version or
> not?

Reading the link fully would show you how, but as far as Debian ics
concerned it only made it to testing and sid. If you run either of
those then Debian's own security announcements cover it.

Thanks,
Andy

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

Re: making Debian secure by default

[Andy Smith]

Hi,

On Fri, Mar 29, 2024 at 05:43:22PM -, Curt wrote:
> On 2024-03-29, Andy Smith  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

Re: making Debian secure by default

[Jeffrey Walton]

On Thu, Mar 28, 2024 at 5:17 PM Lee  wrote:
>
> > Hope this helps a little bit.
>
> Yes, it does.  I was hoping for something simple but it's becoming
> clear to me that there's no simple "make Debian secure for dummies"
> checklist to follow.

Robert Morris Sr. has some good advice,
: It is
easy to run a secure computer system. You merely have to disconnect
all dial-up connections and permit only direct-wired terminals, put
the machine and its terminals in a shielded room, and post a guard at
the door.

You may remember his son, Robert Tappan Morris. He's the author of the
Morris worm from the late 1980s.

Jeff

Re: making Debian secure by default

[Stefan Monnier]

> Yes, it does.  I was hoping for something simple but it's becoming
> clear to me that there's no simple "make Debian secure for dummies"
> checklist to follow.

I think to a significant extent, Debian maintainers do aim to make Debian
"secure by default", to the extent possible (i.e. based on what is
expected to be a "normal/typical" use of the system).

Admittedly, "dummies" is not really the target audience for Debian, so
maybe the defaults aren't quite up to *that* task.


Stefan

Re: making Debian secure by default

[Roberto C . Sánchez]

On Fri, Mar 29, 2024 at 07:02:54PM +0100, Kamil Jońca wrote:
> Andy Smith  writes:
> 
> [...]
> > https://www.openwall.com/lists/oss-security/2024/03/29/4
> >
> > (Upstream xz/lzma project compromised, hostile code inserted into
> > sshd in Debian sid and other leading edge distros.)
> >
> > Thanks,
> > Andy
> 
> O-o, is there any simple test to check if I have infected version or
> not?
> KJ

Yes. It is mentioned in Andres' email and provided as an attachement at
the end.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: making Debian secure by default

[Kamil Jońca]

Andy Smith  writes:

[...]
> https://www.openwall.com/lists/oss-security/2024/03/29/4
>
> (Upstream xz/lzma project compromised, hostile code inserted into
> sshd in Debian sid and other leading edge distros.)
>
> Thanks,
> Andy

O-o, is there any simple test to check if I have infected version or
not?
KJ
-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: making Debian secure by default

[Curt]

On 2024-03-29, Joe  wrote:
>
> He's actually referring to credentials stored externally being

Jesus, what a genius.

Re: making Debian secure by default

[Curt]

On 2024-03-29, Andy Smith  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.

Re: making Debian secure by default

[Joe]

On Fri, 29 Mar 2024 16:53:04 +
Andy Smith  wrote:

> Hello,
> 
> On Thu, Mar 28, 2024 at 05:47:44PM -, Curt wrote:
> > On 2024-03-28, Greg Wooledge  wrote:  
> > >
> > > A more proactive endeavor would be to document known best
> > > practices  
> > 
> > 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?
> 
> https://www.openwall.com/lists/oss-security/2024/03/29/4
> 
> (Upstream xz/lzma project compromised, hostile code inserted into
> sshd in Debian sid and other leading edge distros.)
> 

Hah! Most of us remember Heartbleed.

He's actually referring to credentials stored externally being
compromised. I'm not sure what can be done about that: maybe make some
kind of, you know, law, about storing sensitive data, and prosecuting
people who are responsible for failure to keep it secure... nothing
like accountability for discouraging negligence.

-- 
Joe

Re: making Debian secure by default

[Andy Smith]

Hello,

On Thu, Mar 28, 2024 at 05:47:44PM -, Curt wrote:
> On 2024-03-28, Greg Wooledge  wrote:
> >
> > A more proactive endeavor would be to document known best practices
> 
> 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?

https://www.openwall.com/lists/oss-security/2024/03/29/4

(Upstream xz/lzma project compromised, hostile code inserted into
sshd in Debian sid and other leading edge distros.)

Thanks,
Andy

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

Re: making Debian secure by default

[Curt]

On 2024-03-28, to...@tuxteam.de  wrote:
>
> Security, as Bruce Schneier [1] says, is a process. Not a product.
>

A process that is essentially out of your control.

This is the elephant in the room that you do not wish to address.

Anyway, dream on.

Re: making Debian secure by default

[Jeffrey Walton]

On Wed, Mar 27, 2024 at 8:37 PM Lee  wrote:
>
> I just saw this advisory
>   Escape sequence injection in util-linux wall (CVE-2024-28085)
> https://seclists.org/fulldisclosure/2024/Mar/35
> where they're talking about grabbing other users sudo password.
>
> Apparently the root of the security issue is that wall is a setguid program?
>
> Even more fun is the instructions
>   To make sure the PoC will work, make sure your victim user can
>   actually receive messages. First check that mesg is set to y
>   (`mesg y`). If a user does not have mesg turned on, they are not
>   exploitable.
>
> WTF??  I've never heard of a mesg, but
>   $ which mesg
>   /usr/bin/mesg
>
> So.  There is a program called 'mesg',  hrmmm..
>   man mesg
> ...
>   Traditionally, write access is allowed by default.  However,  as  users
>   become  more  conscious  of various security risks, there is a trend to
>   remove write access by default, at least for the primary  login  shell.
>   To  make  sure  your ttys are set the way you want them to be set, mesg
>   should be executed in your login scripts.
>
> oof.  Are there instructions somewhere on how to make Debian secure by 
> default?

There are Security Technical Implementation Guides (STIG) for Red Hat,
Solaris, SUSE, and Ubuntu. Unfortunately, nothing for Debian. See
.
More generally, for Operating Systems, see
.

Jeff

Re: making Debian secure by default

[Emanuel Berg]

David Wright wrote:

>> Ah, surely it can't refer to that as that would be
>> completely ridiculous as it would imply "wanna install
>> stuff? sure, but then it isn't secure anymore".
>
> It's not clear what "isn't secure anymore" means. [...]

It means as soon as you start doing stuff with the software,
it isn't secure anymore. Which is comical to some extent as
doing stuff is the purpose of computers.

So to base security boasting on people having the most
minimal, restricted and inactive system, it is like boasting
this marvelous piece of body armor is guaranteed to not have
a single infantryman killed - just don't go to war.

(Note that now I'm just making fun at the slogan and boasting,
not saying anything negative of their OS necessarily - I've
used it myself, it send pretty good and, indeed, secure.)

>  "Secure by Default"
>
>  "To ensure that novice users of OpenBSD do not need to
>   become security experts overnight (a viewpoint which other
>   vendors seem to have), we ship the operating system in
>   a Secure by Default mode. All non-essential services are
>   disabled. As the user/administrator becomes more familiar
>   with the system, he will discover that he has to enable
>   daemons and other parts of the system. During the process
>   of learning how to enable a new service, the novice is
>   more likely to learn of security considerations."
>
> from https://www.openbsd.org/security.html
> OTOH:
>
>  "There are many applications one might want to use on an
>   OpenBSD system. To make this software easier to install
>   and manage, it is ported to OpenBSD and packaged. The aim
>   of the package system is to keep track of which software
>   gets installed, so that it may be easily updated or
>   removed. In minutes, a large number of packages can be
>   fetched and installed, with everything put in the
>   right place."
>
>  "The ports collection does not go through the same thorough
>   security audit that is performed on the OpenBSD base
>   system. Although we strive to keep the quality of the
>   packages high, we just do not have enough resources to
>   ensure the same level of robustness and security."
>
> from https://www.openbsd.org/faq/faq15.html (Package
> Management).

The more you install, the less secure it gets. Yeah, can't
base the security model on that.

They should do it the other way around, write a piece of
software that breaks everything. Install in on OpenBSD and if
it breakes it, OpenBSD is not more secure than anyone else.
If nothing happens tho most likekly you are safe.

-- 
underground experts united
https://dataswamp.org/~incal

Re: making Debian secure by default

[Ralph Aichinger]

On Thu, 2024-03-28 at 14:12 -0400, Lee wrote:

> 
> Yes, it does.  I was hoping for something simple but it's becoming
> clear to me that there's no simple "make Debian secure for dummies"
> checklist to follow.

Making "Debian secure for dummies" and having a multi-user system at
the same time does not sense, IMO. If you want to secure your Debian
system, one of the easiest and most important steps is: Don't give
anyone access who you do not trust. 

Having a true multi-user system that shields users from each other is
much much harder, and certainly nothing "dummies" or beginners should
even try.

/ralph

Re: making Debian secure by default

[Jeffrey Walton]

On Thu, Mar 28, 2024 at 5:07 PM Lee  wrote:
> [...]
> > 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.

Wikipedia changes links to the Wayback Machine once a link goes bad.

Jeff

Re: making Debian secure by default

[debian-user]

 wrote:

> [1] https://xkcd.com/1200/

Here in the UK the most important part of that xkcd for most people
simply isn't true. Anything financial has a separate login procedure
and all that I use time out after a period of inactivity (even some
stupid non-important government things). I expect the same is true in
Europe? And I'd be surprised if it isn't true in Murrica too?

So a thief would have to be very lucky! Especially in my case since I
don't own a laptop and never use a phone or suchlike for financial
matters.

Re: making Debian secure by default

[Michael Kjörling]

On 28 Mar 2024 20:30 +, from dnomh...@gmx.com (Richmond):
> I always thought it strange that debian has no firewall on by
> default. Why not offer to enable one during installation? Opensuse
> offers to enable one and offers to allow ssh.

That sounds like a good idea to file as wishlist against
debian-installer.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 4:07 PM Andy Smith  wrote:
>
> Hi,
>
> On Thu, Mar 28, 2024 at 12:22:57PM -0400, Lee wrote:
   ... snip ...
>
> Documentation and integration is perpetually out of date in Linux.

Right.  Intellectually I know that; emotionally I find it a bit
difficult to accept.

> Also no one can agree on which documentation is canonical,

another area I'm struggling to accept.  Seeing referrals to the Arch
wiki on a debian mailing list just seems wrong..

> > Is there really nothing better than sudo find /  > files with uid or gid perms> and try to figure out which of those
> > program are not necessary?
>
> I don't think there is, no. After finding each of those things you
> would need to do some research on each one.

Right.  That's what I was trying to avoid.

> Those that are
> particularly worrisome probably already do have some notes
> somewhere.
>
> > $ sudo crontab -l
> >...
> >  47  4  *  *  *  (apt update >> apt-update.log 2>/dev/null) && \
> >   (apt list --upgradable 2>/dev/null |\
> >   egrep -v '^Listing' >| /etc/motd)
>
> You may like to look in to "apticron-systemd" for a systemd timer
> that does the above.

Nope.  I can't remember what I asked on this list years ago, but I got
a few suggestions on how to be notified about software updates and
ended up writing my own script.  If nothing else, I trust it to work
properly.
I also trust that if there's a problem with my script someone will let
me know :)

Thanks,
Lee

Re: making Debian secure by default

[Michael Kjörling]

On 28 Mar 2024 15:28 -0400, from g...@wooledge.org (Greg Wooledge):
>> so apparently somebody else has done a threat analysis and decided
>> apparmor is the appropriate mitigation strategy?
> 
> *An* appropriate mitigation strategy.  Not "the".
> 
> There are many, many layers.

Right. We've got everything from address space layout randomization
(ASLR), firewalling, full-disk encryption (for example with LUKS) and
automatic system updates all the way to password policies,
file/directory access permissions and system call masking. There is
the concept of data backups, storage-level redundancy, SMART
monitoring and system log analysis. It's possible to choose between
encrypted SSH and plain-text telnet or rsh for remote shell access
(and these days, no one should suggest the latter, but I digress).
Each of which can help mitigate _some_ threats and is utterly useless
against others.

Even within each of those there are differences. For example, a _lot_
of people and guides say, essentially unconditionally, "Thou Shall
Disable SSH Password Authentication". That's good advice in some
situations and _horrible_ advice in other situations.

It's not particularly meaningful to make a threat assessment for
"Debian". (It might very well be meaningful to make a threat
assessment for _the Debian project_, but that's something very
different.) What certainly _is_ meaningful is to make a threat
assessment for your computer, your data, your network and your usage.

Which will almost certainly be very different from mine, or Alice's,
or Bob's; never mind between my desktop system, Carol's server and
Mallory's laptop; and therefore will require a different
implementation.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: making Debian secure by default

[Richmond]

Lee  writes:

>
> oof.  Are there instructions somewhere on how to make Debian secure by
> default?
>
> Thanks, Lee

I always thought it strange that debian has no firewall on by
default. Why not offer to enable one during installation? Opensuse
offers to enable one and offers to allow ssh.

Re: making Debian secure by default

[David Wright]

On Thu 28 Mar 2024 at 12:36:56 (+0100), Emanuel Berg wrote:
> Michael Kjörling wrote:
> 
> >> "Secure by default" is an OpenBSD slogan BTW. Or they have
> >> made it into one at least. But I'm not sure it is any more
> >> secure than Debian - maybe.
> >> 
> >>   https://www.openbsd.org/security.html
> >
> > If I'm not mistaken, OpenBSD is "secure by default" by being
> > "extremely minimalistic by default".
> >
> > Last I looked, which in fairness was a while ago, a default
> > installation of OpenBSD includes almost nothing that normal,
> > present-day users would expect to find on their system. [...]
> 
> Ah, surely it can't refer to that as that would be completely
> ridiculous as it would imply "wanna install stuff? sure, but
> then it isn't secure anymore".

It's not clear what "isn't secure anymore" means. But anyway,

 “"Secure by Default"

 “To ensure that novice users of OpenBSD do not need to become
  security experts overnight (a viewpoint which other vendors seem to
  have), we ship the operating system in a Secure by Default mode.
  All non-essential services are disabled. As the user/administrator
  becomes more familiar with the system, he will discover that he has
  to enable daemons and other parts of the system. During the process
  of learning how to enable a new service, the novice is more likely
  to learn of security considerations.”

from https://www.openbsd.org/security.html
OTOH:

 “There are many applications one might want to use on an OpenBSD
  system. To make this software easier to install and manage, it is
  ported to OpenBSD and packaged. The aim of the package system is to
  keep track of which software gets installed, so that it may be easily
  updated or removed. In minutes, a large number of packages can be
  fetched and installed, with everything put in the right place.

 “The ports collection does not go through the same thorough security
  audit that is performed on the OpenBSD base system. Although we
  strive to keep the quality of the packages high, we just do not have
  enough resources to ensure the same level of robustness and
  security.”

from https://www.openbsd.org/faq/faq15.html (Package Management).

Cheers,
David.

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 2:32 PM Andy Smith  wrote:
>
> Hello,
>
> On Thu, Mar 28, 2024 at 11:24:08AM -0400, Greg Wooledge wrote:
> > On Thu, Mar 28, 2024 at 01:30:32PM +, Andy Smith wrote:
> > > 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.
>
> Personally I'll read the handbook before the wiki, but I'm fairly
> confident that the vast majority of users will read neither. 
>
> Which leads me to ask OP which hardening documents have they
> actually already read, and would the advice be suitable for those?

Read and understood?  None

I have looked at the Debian Administrator's Manual and the Securing
Debian Manual.  I'll bet not enough has sunk in though.

Years ago, I had to do CIS router security benchmarks for work so I
know what went into a network security analysis & how much background
knowledge was necessary to implement the policy ..  Which is why I'm
_sure_ I don't have enough background knowledge to do an adequate
threat analysis for a Debian machine.

I guess I'm just lazy :)  and looking for a short-cut instead of doing
the hard work and figuring it out for myself.

Regards,
Lee

Re: making Debian secure by default

[tomas]

On Thu, Mar 28, 2024 at 03:23:48PM -0400, Lee wrote:

[...]

> I disagree.  I don't think I'm qualified to make an adequate threat
> analysis for a Debian system and yet

Nobody is. The threat analysis for my virtual server "out there" is
totally different (sshd, exim, http(s), git running on external ports,
yadda, yadda), but running 24/7 in some physically protected data
center; for my laptop, most of the time behind a firewall, but running
a web browser *and* phisically insecure (can be stolen/left behind).

So in the first case it makes sense to focus on network hardening,
whereas disk encryption is an unnecessary hassle (ever tried to boot
from a LUKS disk remotely? Yes, I know it /can/ be done). In the
second case disk encryption is a /must/ (as it is to keep up to date
with it).

How would you make a threat analysis "for Debian"? That makes no
sense. The only you can do is to document the security properties of
each and every component and use that as a toolkit for your particular
use case.

Security, as Bruce Schneier [1] says, is a process. Not a product.

Cheers

[1] https://www.schneier.com/
-- 
t


signature.asc
Description: PGP signature

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 1:48 PM Curt wrote:
>
> On 2024-03-28, Greg Wooledge wrote:
> >
> > A more proactive endeavor would be to document known best practices
>
> It makes no fucking difference, because your important data is elsewhere
> and completely out of your control.

Agreed - your important data is elsewhere and completely out of your
control.  But I don't think that's a good reason to quit trying.

Regards,
Lee

Re: making Debian secure by default

[Greg Wooledge]

On Thu, Mar 28, 2024 at 03:23:48PM -0400, Lee wrote:
> so apparently somebody else has done a threat analysis and decided
> apparmor is the appropriate mitigation strategy?

*An* appropriate mitigation strategy.  Not "the".

There are many, many layers.

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 1:28 PM tomas wrote:
>
> On Thu, Mar 28, 2024 at 12:22:57PM -0400, Lee wrote:
> > On Thu, Mar 28, 2024 at 1:11 AM tomas wrote:
>
> [...]
>
> > > Security means first and foremost understanding the threat.
> >
> > Which I don't.  Hence the request for 'secure by default' instructions
> > for Debian.  Even better would be a secure by default installation
> > option.
>
> This makes little sense. No threat analysis -- no security. Security
> is always a relative (to the threat model) term, "security by default"
> suggests something absolute. This ain't going to work.

I disagree.  I don't think I'm qualified to make an adequate threat
analysis for a Debian system and yet
  $ sudo aa-status
  apparmor module is loaded.
  21 profiles are loaded.
  19 profiles are in enforce mode.
 ...
  6 processes are in enforce mode.

so apparently somebody else has done a threat analysis and decided
apparmor is the appropriate mitigation strategy?

I'm coming to the realization that more is wishful thinking, but
still.. it would be nice if I didn't feel like I was facing such an
overwhelmingly steep learning curve.

Regards,
Lee

Re: making Debian secure by default

[Lee]

> Hope this helps a little bit.

Yes, it does.  I was hoping for something simple but it's becoming
clear to me that there's no simple "make Debian secure for dummies"
checklist to follow.

Thanks,
Lee


On Thu, Mar 28, 2024 at 11:43 AM Hans wrote:
>
> Hello,
> personally I think, the best way is to plan, what you want to do with your
> system. What is its task. How secure it shall be.
>
> And then just think of: What can happen? For example: Can someone boot wirt an
> external medium? Do more than one people got admin rights? How do people
> access? Can the server be stolen? And so on.
>
> Make a list, do brainsorming with other people. Learn from other hacks.
>
> And then act for every point you made. Think, how can this and this and this
> attack be inhibited, how can it be noticed and is there an alarm and so on.
>
> For my personal experience, I never saw an attack in the past, which was not
> prepared. Before are runninng portscans or simple bruteforce attacks.
>
> Here I am talking of activists and script kiddies, not APT's. APT's are much
> more difficult to defend and to discover, they can, but very, very difficult.
>
> A good point to start is the doc "securing debian", and then, after you did
> this, think of, what you have forgotten and what did the docu not tell.
>
> IT-Security is no software, it is a process, and you will have to learn for
> years, which is normal. The attackers learn, the defenders, too.
>
> There is no straight, golden way, every server is different, and so are its
> defence. As I said, its a concept, and this can change during the years.
>
> Hope this helps a little bit.
>
> Best regards
>
> Hans

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 11:24 AM Greg Wooledge  wrote:
>
> On Thu, Mar 28, 2024 at 01:30:32PM +, 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

Re: making Debian secure by default

[Curt]

On 2024-03-28, Greg Wooledge  wrote:
>
> A more proactive endeavor would be to document known best practices

It makes no fucking difference, because your important data is elsewhere
and completely out of your control.

Re: making Debian secure by default

[tomas]

On Thu, Mar 28, 2024 at 12:22:57PM -0400, Lee wrote:
> On Thu, Mar 28, 2024 at 1:11 AM tomas wrote:

[...]

> > Security means first and foremost understanding the threat.
> 
> Which I don't.  Hence the request for 'secure by default' instructions
> for Debian.  Even better would be a secure by default installation
> option.

This makes little sense. No threat analysis -- no security. Security
is always a relative (to the threat model) term, "security by default"
suggests something absolute. This ain't going to work.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: making Debian secure by default

[Florent Rougon]

Le 28/03/2024, Greg Wooledge  a écrit:

> You can't stop root from writing to your terminal.  Root has write
> privileges on all devices.
>
> The purpose of mesg is to allow *other regular users* to send you
> messages, or not. (...)

Indeed, I understood that after running 'ls -la $(tty)', as suggested
elsewhere by Andy. Thanks for the complement and all your useful
messages.

Regards

-- 
Florent

Re: making Debian secure by default

[Andy Smith]

Hi,

On Thu, Mar 28, 2024 at 12:22:57PM -0400, Lee wrote:
> For heavens sake, the man page says
> 
>Traditionally, write access is allowed by default.  However,  as  users
>become  more  conscious  of various security risks, there is a trend to
>remove write access by default, at least for the primary  login  shell.
>To  make  sure  your ttys are set the way you want them to be set, mesg
>should be executed in your login scripts.
> 
> Clearly at least the man page writer realized there was a threat there
> _and chose not to remove the threat_ !?

For context, that was likely written by someone a decade or more
ago, someone who did not have responsibility for any other part of
Linux. Since that time even the parts that were in charge of setting
terminal permissions might have changed implementation and
maintainers several times.

It's not that they chose not to keep the rest of the system
consistent with their opinion, it's more likely that they could not.

Documentation and integration is perpetually out of date in Linux.
Also no one can agree on which documentation is canonical, and very
few people read any of it. I'm just as guilty as anyone: having no
use for "wall" or "mesg" for decades, I hadn't read its man page and
didn't notice that terminals were group-writeable.

> Is there really nothing better than sudo find /  files with uid or gid perms> and try to figure out which of those
> program are not necessary?

I don't think there is, no. After finding each of those things you
would need to do some research on each one. Those that are
particularly worrisome probably already do have some notes
somewhere.

> $ sudo crontab -l
>...
>  47  4  *  *  *  (apt update >> apt-update.log 2>/dev/null) && \
>   (apt list --upgradable 2>/dev/null |\
>   egrep -v '^Listing' >| /etc/motd)

You may like to look in to "apticron-systemd" for a systemd timer
that does the above. (drop the "-systemd" if you prefer a cron job
equivalent)

apticorn is mentioned in the Debian Administrator's Handbook which
is worth a read even though it only covers up to Debian 11.


https://www.debian.org/doc/manuals/debian-handbook/sect.regular-upgrades.en.html

Thanks,
Andy

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

Re: making Debian secure by default

[Greg Wooledge]

On Thu, Mar 28, 2024 at 05:23:36PM +0100, Florent Rougon wrote:
> Did anyone try 'mesg n' here? I tried:
> 
> 
> $ mesg n
> $ mesg; echo $?
> is n
> 1
> 
> Broadcast message from root@hostname (pts/1) (Thu Mar 28 16:48:13 2024):
> 
> pouet

You can't stop root from writing to your terminal.  Root has write
privileges on all devices.

The purpose of mesg is to allow *other regular users* to send you
messages, or not.  People have focused so much on "wall" in this
thread, but wall is usually used by root, or by the OS itself, to
send broadcast notices of major events like impending reboots.

The more common tool for users to talk to each other on their terminals
is write(1).  Or if you wanted to have a conversation, there's talk(1).
Or rather, there's supposed to be talk(1).  I have a POSIX man page
for it, but not a Debian one, and the program itself doesn't appear to
be installed.  Maybe it's in a separate package.

I have write(1) from the bsdextrautils package.  There is a talk package
but I haven't installed it.

Re: making Debian secure by default

[Florent Rougon]

Le 28/03/2024, Florent Rougon  a écrit:

> Did I miss the point of 'mesg n'?..

Ugh, sorry. Thanks to the 'ls -la $(tty)' command Andy Smith wrote in
another message, I understood:

  'mesg n' does prevent users from writing to your terminal using e.g.
  'wall', *except* if said users are either root or yourself.

So I redid the above test but using 'wall' from *another* non-root
account: 'mesg n' did prevent the messages from coming through, and
'mesg y' allowed them again.

All good. :-)

Regards

-- 
Florent

Re: making Debian secure by default

[Andy Smith]

Hi,

On Thu, Mar 28, 2024 at 05:21:21PM +0100, Michel Verdier wrote:
> On 2024-03-28, Marc SCHAEFER wrote:
> >> Apparently the root of the security issue is that wall is a setguid 
> >> program?
> >
> > a) wall must be able to write to your tty, which is not possible
> >if wall is not installed setguid OR if people have sane permissions
> >on their terminals (e.g. set to mesg n)
> 
> Found in /etc/login.defs :

Is login.defs actually used by modern Debian with PAM? I seem to
recall lots of things in there are controlled by PAM instead now.

Looking at all of my sessions, the terminal file for all of them is
group writeable despite "TTYPERM 0600" being in /etc/login.defs.

$ ls -la $(tty)
crw--w 1 andy tty 136, 0 Mar 28 16:33 /dev/pts/0
$ mesg
is y
$ mesg n
$ ls -la $(tty)
crw--- 1 andy tty 136, 0 Mar 28 16:34 /dev/pts/0

Thanks,
Andy

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

Re: making Debian secure by default

[Franco Martelli]

On 28/03/24 at 12:05, Marc SCHAEFER wrote:

Hello,

On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:

Apparently the root of the security issue is that wall is a setguid program?


a) wall must be able to write to your tty, which is not possible
if wall is not installed setguid OR if people have sane permissions
on their terminals (e.g. set to mesg n)

b) in addition, for this exploit to run, command-not-found must be
started with the not found command as argument: in the two Debian
releases I just tried (buster and bookworm), with bash,
command-not-found was not installed.

The idea of the exploit is that you get a prompt for entering a sudo
password, which is a simple text (which gets more convincing because
of a recently introduced bug in wall which does not filter out terminal
escape / control sequences), then you type the root password, which
is presumably not the name of an existing command, so command-not-found
PASSWORD is run, and someone on another terminal and user can do
a ps to see that password argument if he is quick or polling.

To fix this:

a) don't type a root password / sudo password unless you know that
it should happen

b) don't allow others to write on your terminals, in particular
if you run priviledged commands and expect sudo prompts

c) patch wall so that its texts are always shown to be
different from other program outputs (== filter out
anything else than printable characters)

THIS IS MY PREFERRED WORKAROUND :)
(mixing controls (prompts) and data is always
 a very bad idea)

d) don't have other users on your machine / use containers.


Do you know whether it exists a tutorial/wiki that explain how to avoid 
users in favor to containers?


Thanks in advance

--
Franco Martelli

Re: making Debian secure by default

[Florent Rougon]

Hi,

Le 27/03/2024, Andy Smith  a écrit:

> You could put a call to "mesg n" into a file in /etc/profile.d so
> that all users execute it.

Did anyone try 'mesg n' here? I tried:


$ mesg n
$ mesg; echo $?
is n
1

Broadcast message from root@hostname (pts/1) (Thu Mar 28 16:48:13 2024):

pouet


Broadcast message from simpleuser@hostname (pts/3) (Thu Mar 28 16:48:49 2024):

a



Did I miss the point of 'mesg n'?..

Thanks, regards

-- 
Florent

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 1:11 AM tomas wrote:
>
> On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> > I just saw this advisory
> >   Escape sequence injection in util-linux wall (CVE-2024-28085)
> > https://seclists.org/fulldisclosure/2024/Mar/35
> > where they're talking about grabbing other users sudo password.
>
> Are there any users logged in to your computer you dont't trust?
>
> Thought so.
>
> Relax.
>
> Security means first and foremost understanding the threat.

Which I don't.  Hence the request for 'secure by default' instructions
for Debian.  Even better would be a secure by default installation
option.

To be clear, I'm not all that concerned about _this_ CVE.  I've got
the disable_mesg.sh file in /etc/profile.d so sending messages with
control codes to other terminals should be disabled for all.

My concern is all the other stuff that I don't even know about that
could be configured in a more secure manner but isn't.  For heavens
sake, the man page says

   Traditionally, write access is allowed by default.  However,  as  users
   become  more  conscious  of various security risks, there is a trend to
   remove write access by default, at least for the primary  login  shell.
   To  make  sure  your ttys are set the way you want them to be set, mesg
   should be executed in your login scripts.

Clearly at least the man page writer realized there was a threat there
_and chose not to remove the threat_ !?

So what other goodies are there that I don't know about?  Is there
really nothing better than sudo find /  and try to figure out which of those program are not
necessary?

And I'm still a bit surprised that needrestart isn't included as part
of the default install.  Or at least as part of the synaptic package
manager install.  I never guessed that I would _not_ be warned that I
needed to reboot after updating software with the synaptic package
manager -- that didn't happen until after I installed needrestart.

> Randomly
> reaching into the CVE box will most probably keep you from actually
> working on your real issues. E.g. your browser.

I think it's up to date:
$ cat /etc/motd

lee@spot ~
$ sudo crontab -l
[sudo] password for lee:
   ...
 47  4  *  *  *  (apt update >> apt-update.log 2>/dev/null) && \
  (apt list --upgradable 2>/dev/null |\
  egrep -v '^Listing' >| /etc/motd)

> Or your social media
> account.

I've never had one.

> Cheers
>
> [1] https://xkcd.com/1200/

I like the quote I saved from the full disclosure mailing list back
when it was fun & exploits were mailed out as attachments:

And at some point, you really have to ask yourself "Is this really a
plausible attack method, or did I forget to take my meds again?"
   -- Valdis Kletnieks

Regards
Lee

Re: making Debian secure by default

[Michel Verdier]

On 2024-03-28, Marc SCHAEFER wrote:

>> Apparently the root of the security issue is that wall is a setguid program?
>
> a) wall must be able to write to your tty, which is not possible
>if wall is not installed setguid OR if people have sane permissions
>on their terminals (e.g. set to mesg n)

Found in /etc/login.defs :

#
# Terminal permissions
#
#   TTYGROUPLogin tty will be assigned this group ownership.
#   TTYPERM Login tty will be set to this permission.
#
# If you have a "write" program which is "setgid" to a special group
# which owns the terminals, define TTYGROUP to the group number and
# TTYPERM to 0620.  Otherwise leave TTYGROUP commented out and assign
# TTYPERM to either 622 or 600.
#
# In Debian /usr/bin/bsd-write or similar programs are setgid tty
# However, the default and recommended value for TTYPERM is still 0600
# to not allow anyone to write to anyone else console or terminal

# Users can still allow other people to write them by issuing 
# the "mesg y" command.

TTYGROUPtty
TTYPERM 0600

My tty is set to 0600 and even with "mesg y" only root can send a message
with wall. Am I missing something ?

Re: making Debian secure by default

[Andy Smith]

Hello,

On Thu, Mar 28, 2024 at 11:24:08AM -0400, Greg Wooledge wrote:
> On Thu, Mar 28, 2024 at 01:30:32PM +, Andy Smith wrote:
> > 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.

Personally I'll read the handbook before the wiki, but I'm fairly
confident that the vast majority of users will read neither. 

Which leads me to ask OP which hardening documents have they
actually already read, and would the advice be suitable for those?

Thanks,
Andy

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

Re: making Debian secure by default

[Hans]

Hello,
personally I think, the best way is to plan, what you want to do with your 
system. What is its task. How secure it shall be.

And then just think of: What can happen? For example: Can someone boot wirt an 
external medium? Do more than one people got admin rights? How do people 
access? Can the server be stolen? And so on.

Make a list, do brainsorming with other people. Learn from other hacks.

And then act for every point you made. Think, how can this and this and this 
attack be inhibited, how can it be noticed and is there an alarm and so on.

For my personal experience, I never saw an attack in the past, which was not 
prepared. Before are runninng portscans or simple bruteforce attacks.

Here I am talking of activists and script kiddies, not APT's. APT's are much 
more difficult to defend and to discover, they can, but very, very difficult.

A good point to start is the doc "securing debian", and then, after you did 
this, think of, what you have forgotten and what did the docu not tell.

IT-Security is no software, it is a process, and you will have to learn for 
years, which is normal. The attackers learn, the defenders, too.

There is no straight, golden way, every server is different, and so are its 
defence. As I said, its a concept, and this can change during the years.

Hope this helps a little bit.

Best regards

Hans


  

Re: making Debian secure by default

[Greg Wooledge]

On Thu, Mar 28, 2024 at 01:30:32PM +, 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.

Re: making Debian secure by default

[Curt]

On 2024-03-28,   wrote:
>
> Security means first and foremost understanding the threat. Randomly

The threat here is that some pharmacist in the provinces falls for a
phishing email, gives black hats access to the system, and reveals my
sensitive data to these people who devised the alluringly convincing
electronic missive.

This is precisely what happened here in France not long ago to half the
population. The user of the French health-care system can do nothing to
obviate this threat. There is no remedy for the foibles of other men.

Re: making Debian secure by default

[Andy Smith]

On Thu, Mar 28, 2024 at 12:28:56AM -0400, Lee wrote:
> On Wed, Mar 27, 2024 at 10:07 PM Andy Smith wrote:
> >
> > Hi,
> >
> > On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> > > I just saw this advisory
> > >   Escape sequence injection in util-linux wall (CVE-2024-28085)
> > > https://seclists.org/fulldisclosure/2024/Mar/35
> > > where they're talking about grabbing other users sudo password.
> >
> > It doesn't work by default on Debian as it relies on
> > command-not-found automatically running on the user's input.
> > command-not-found can be installed, however…
> >
> > > oof.  Are there instructions somewhere on how to make Debian secure by 
> > > default?
> >
> > Between the fact that "secure" means different things to different
> > people and that this advisory was only released a few hours ago, I
> > don't think you can reasonably expect documentation to already be
> > published for your standard of "secure".
> 
> You snipped the bit from the man page about users becoming more more
> conscious of various security risks & removing write access by
> default.

It's just an opinion by the author of the man page.

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.

> Considering how long it takes something to migrate into stable I'm
> guessing that man page is pretty old.  So I don't think it's
> unreasonable to expect some kind of secure by default installation
> option.

I wouldn't be surprised if the man page is 10 years old. Linux
distributions do not tend to be that internally consistent. Lots of
weird things get put into man pages by their authors and
distributions don't always feel obliged to obey all of them;
sometimes they are even conflicting between each other.

Things are more coherent in BSD land, where the base system is
developed alongside the kernel, by the same people.

I do agree with you though that "mesg n" would be a much better
default and it's a shame we worked that out by seeing a ten year old
bug revealed.

It might be worth submitting a wishlist bug to Debian. I'm not
entirely sure of which package but I suppose "util-linux" would make
sense since that's where "mesg" comes from. It could ask for a shell
snippet in profile.d to set the default to "n" in the name of
security, and reference this CVE.

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.

> > As you've never heard of "mesg" and probably don't use "wall" I
> > doubt you will have any issues chmod 0 /usr/bin/wall and then
> > setting it immutable¹ with chattr +i.
> 
> I suppose that's one way.  I'd rather uninstall it.

Problem is it's part of "bsdutils" so that would uninstall the whole
package and all its other tools.

A divert (man dpkg-divert) ciuld be used to remove the binary, but I
prefer chmod 0 and immutable as a less drastic approach.

There is also the issue that the user's terminal remains writeable by
processes in "tty" group - all that's been achieved is to stop one
program that has a known bug from doing so. There could be others,
and we've established that most users probably do not want or need
other users to write to their terminals. So "mesg n" is still a good
idea.

Thanks,
]Andy

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

Re: making Debian secure by default

[Emanuel Berg]

Michael Kjörling wrote:

>> "Secure by default" is an OpenBSD slogan BTW. Or they have
>> made it into one at least. But I'm not sure it is any more
>> secure than Debian - maybe.
>> 
>>   https://www.openbsd.org/security.html
>
> If I'm not mistaken, OpenBSD is "secure by default" by being
> "extremely minimalistic by default".
>
> Last I looked, which in fairness was a while ago, a default
> installation of OpenBSD includes almost nothing that normal,
> present-day users would expect to find on their system. [...]

Ah, surely it can't refer to that as that would be completely
ridiculous as it would imply "wanna install stuff? sure, but
then it isn't secure anymore".

-- 
underground experts united
https://dataswamp.org/~incal

Re: making Debian secure by default

[Michael Kjörling]

On 28 Mar 2024 06:16 +0100, from in...@dataswamp.org (Emanuel Berg):
> "Secure by default" is an OpenBSD slogan BTW. Or they have
> made it into one at least. But I'm not sure it is any more
> secure than Debian - maybe.
> 
>   https://www.openbsd.org/security.html

If I'm not mistaken, OpenBSD is "secure by default" by being
"extremely minimalistic by default".

Last I looked, which in fairness was a while ago, a default
installation of OpenBSD includes almost nothing that normal,
present-day users would expect to find on their system. Once you go
beyond the default installation by adding useful packages, you also go
beyond at least a large part of the "secure by default" promise.

And similarly that most network-enabled software installs by default
with all network-related functionality turned off or heavily
restricted, so the first thing you have to do after installing
something is to turn on the functionality for which you installed it.
But up until the point that you do that, the software you installed
very likely is secure (because it's reachable at most by people you
already trust at least to some degree).

Which doesn't mean that Debian can't be "more secure by default" by
installing services in a turned-off and locked-down manner and
expecting the administrator to open them up and do so in a secure
manner. But I rather suspect that most people who do install a package
do so because they want to use it; so a reasonably secure but still
useful setup out of the package manager would seem more practically
useful to most people.

Security and usability are often (but not always) at odds with each
other. The most secure system possible generally won't be very usable.

And for a real-world use case for wall, I have apcupsd set up to send
notifications to everywhere if there's a power failure, and ahead of a
power-failure system shutdown. Doesn't make much difference if I am at
the console, but is very useful if I'm logged in remotely.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: making Debian secure by default

[Marc SCHAEFER]

Hello,

On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> Apparently the root of the security issue is that wall is a setguid program?

a) wall must be able to write to your tty, which is not possible
   if wall is not installed setguid OR if people have sane permissions
   on their terminals (e.g. set to mesg n)

b) in addition, for this exploit to run, command-not-found must be
   started with the not found command as argument: in the two Debian
   releases I just tried (buster and bookworm), with bash,
   command-not-found was not installed.

The idea of the exploit is that you get a prompt for entering a sudo
password, which is a simple text (which gets more convincing because
of a recently introduced bug in wall which does not filter out terminal
escape / control sequences), then you type the root password, which
is presumably not the name of an existing command, so command-not-found
PASSWORD is run, and someone on another terminal and user can do
a ps to see that password argument if he is quick or polling.

To fix this:

a) don't type a root password / sudo password unless you know that
   it should happen

b) don't allow others to write on your terminals, in particular
   if you run priviledged commands and expect sudo prompts

c) patch wall so that its texts are always shown to be
   different from other program outputs (== filter out
   anything else than printable characters)

   THIS IS MY PREFERRED WORKAROUND :)
   (mixing controls (prompts) and data is always
a very bad idea)

d) don't have other users on your machine / use containers.

> So.  There is a program called 'mesg',  hrmmm..

30 years ago it was common practice to use wall (to signal stuff to
users, e.g. used by shutdown(8)).

> oof.  Are there instructions somewhere on how to make Debian secure by 
> default?

Looks like it is, by not installing command-not-found by default
(apparently Ubuntu does).  Presumably by chance.

Re: making Debian secure by default

[tomas]

On Thu, Mar 28, 2024 at 06:16:32AM +0100, Emanuel Berg wrote:
> "Secure by default" is an OpenBSD slogan BTW. Or they have
> made it into one at least. But I'm not sure it is any more
> secure than Debian - maybe.

That depends.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: making Debian secure by default

[Emanuel Berg]

"Secure by default" is an OpenBSD slogan BTW. Or they have
made it into one at least. But I'm not sure it is any more
secure than Debian - maybe.

  https://www.openbsd.org/security.html

-- 
underground experts united
https://dataswamp.org/~incal

Re: making Debian secure by default

[tomas]

On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> I just saw this advisory
>   Escape sequence injection in util-linux wall (CVE-2024-28085)
> https://seclists.org/fulldisclosure/2024/Mar/35
> where they're talking about grabbing other users sudo password.

Are there any users logged in to your computer you dont't trust?

Thought so.

Relax.

Security means first and foremost understanding the threat. Randomly
reaching into the CVE box will most probably keep you from actually
working on your real issues. E.g. your browser. Or your social media
account.

Cheers

[1] https://xkcd.com/1200/
-- 
t


signature.asc
Description: PGP signature

Re: making Debian secure by default

[Lee]

On Wed, Mar 27, 2024 at 10:22 PM Andy Smith wrote:
>
> Hello,
>
> On Thu, Mar 28, 2024 at 07:37:13AM +0800, jeremy ardley wrote:
> >   Some distros, like Debian, do not seem to have a command like
> >   command-not-found by default.
>
> […]
>
> > Which implies that Debian is secure by default against this particular
> > exploit
>
> I suspect if OP is worried about users potentially falling for a
> fake sudo password prompt then OP is probably not happy about all
> the other possibilities around putting arbitrary text on a user's
> terminal.

Yes, that.

I'm not thrilled with the idea of anybody putting arbitrary text on
someone else's terminal; what really concerns me is the ability to
send control codes.  Wasn't there some exploit that involved injecting
text and a control code that acted like a carriage return?

Lee

Re: making Debian secure by default

[Lee]

On Wed, Mar 27, 2024 at 10:07 PM Andy Smith wrote:
>
> Hi,
>
> On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> > I just saw this advisory
> >   Escape sequence injection in util-linux wall (CVE-2024-28085)
> > https://seclists.org/fulldisclosure/2024/Mar/35
> > where they're talking about grabbing other users sudo password.
>
> It doesn't work by default on Debian as it relies on
> command-not-found automatically running on the user's input.
> command-not-found can be installed, however…
>
> > oof.  Are there instructions somewhere on how to make Debian secure by 
> > default?
>
> Between the fact that "secure" means different things to different
> people and that this advisory was only released a few hours ago, I
> don't think you can reasonably expect documentation to already be
> published for your standard of "secure".

You snipped the bit from the man page about users becoming more more
conscious of various security risks & removing write access by
default.
Considering how long it takes something to migrate into stable I'm
guessing that man page is pretty old.  So I don't think it's
unreasonable to expect some kind of secure by default installation
option.

> There is a general push to get rid of setuid/setgid binaries. A lot
> of "hardening" guides will suggest looking for setuid/setgid
> binaries and deciding if you really need them.

The problem with that is how many users are knowledgeable enough to
know if something is necessary or not?

> As you've never heard of "mesg" and probably don't use "wall" I
> doubt you will have any issues chmod 0 /usr/bin/wall and then
> setting it immutable¹ with chattr +i.

I suppose that's one way.  I'd rather uninstall it.

> You could put a call to "mesg n" into a file in /etc/profile.d so
> that all users execute it.

Good idea:
$ ls -l /etc/profile.d/disable_mesg.sh
-rw-r--r-- 1 root root 383 Mar 28 00:15 /etc/profile.d/disable_mesg.sh

$ cat /etc/profile.d/disable_mesg.sh
# man mesg
#...
#  Traditionally, write access is allowed by default.  However,  as  users
#  become  more  conscious  of various security risks, there is a trend to
#  remove write access by default, at least for the primary  login  shell.
#  To  make  sure  your ttys are set the way you want them to be set, mesg
#  should be executed in your login scripts.

/usr/bin/mesg n


Then logout / login and..
$ mesg
is n

Thanks
Lee

Re: making Debian secure by default

[Andy Smith]

Hello,

On Thu, Mar 28, 2024 at 07:37:13AM +0800, jeremy ardley wrote:
>   Some distros, like Debian, do not seem to have a command like
>   command-not-found by default.

[…]

> Which implies that Debian is secure by default against this particular
> exploit

I suspect if OP is worried about users potentially falling for a
fake sudo password prompt then OP is probably not happy about all
the other possibilities around putting arbitrary text on a user's
terminal.

Also as mentioned, command-not-found is packaged in Debian…

Getting rid of the "wall" command seems reasonable for most people.
It's been almost 30 years since I used it for anything useful.

Thanks,
Andy

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

Re: making Debian secure by default

[jeremy ardley]

On 28/3/24 05:30, Lee wrote:

oof.  Are there instructions somewhere on how to make Debian secure by default?



Further down the advisory is

"

  Some distros, like Debian, do not seem to have a command like
  command-not-found by default. There does not seem to be a way to
  leak a users password in this case then, even though we can send
  escape sequences to them.

"

Which implies that Debian is secure by default against this particular 
exploit

Re: making Debian secure by default

[Andy Smith]

Hi,

On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> I just saw this advisory
>   Escape sequence injection in util-linux wall (CVE-2024-28085)
> https://seclists.org/fulldisclosure/2024/Mar/35
> where they're talking about grabbing other users sudo password.

It doesn't work by default on Debian as it relies on
command-not-found automatically running on the user's input.
command-not-found can be installed, however…

> oof.  Are there instructions somewhere on how to make Debian secure by 
> default?

Between the fact that "secure" means different things to different
people and that this advisory was only released a few hours ago, I
don't think you can reasonably expect documentation to already be
published for your standard of "secure".

There is a general push to get rid of setuid/setgid binaries. A lot
of "hardening" guides will suggest looking for setuid/setgid
binaries and deciding if you really need them.

As you've never heard of "mesg" and probably don't use "wall" I
doubt you will have any issues chmod 0 /usr/bin/wall and then
setting it immutable¹ with chattr +i.

You could put a call to "mesg n" into a file in /etc/profile.d so
that all users execute it.

Thanks,
Andy

¹ The next update of bsdutils will complain it can't write that file.

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

making Debian secure by default

[Lee]

I just saw this advisory
  Escape sequence injection in util-linux wall (CVE-2024-28085)
https://seclists.org/fulldisclosure/2024/Mar/35
where they're talking about grabbing other users sudo password.

Apparently the root of the security issue is that wall is a setguid program?

Even more fun is the instructions
  To make sure the PoC will work, make sure your victim user can
  actually receive messages. First check that mesg is set to y
  (`mesg y`). If a user does not have mesg turned on, they are not
  exploitable.

WTF??  I've never heard of a mesg, but
  $ which mesg
  /usr/bin/mesg

So.  There is a program called 'mesg',  hrmmm..
  man mesg
...
  Traditionally, write access is allowed by default.  However,  as  users
  become  more  conscious  of various security risks, there is a trend to
  remove write access by default, at least for the primary  login  shell.
  To  make  sure  your ttys are set the way you want them to be set, mesg
  should be executed in your login scripts.

oof.  Are there instructions somewhere on how to make Debian secure by default?

Thanks,
Lee