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.
oof. Are there instructions somewhere on how to make Debian secure by default?
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 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.
"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.
Apparently the root of the security issue is that wall is a setguid program?
So. There is a program called 'mesg', hrmmm..
oof. Are there instructions somewhere on how to make Debian secure by default?
"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. [...]
"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
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.
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.
Security means first and foremost understanding the threat. Randomly
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.
On Thu, Mar 28, 2024 at 01:30:32PM +0000, 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.
You could put a call to "mesg n" into a file in /etc/profile.d so
that all users execute it.
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)
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 :
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
Did I miss the point of 'mesg n'?..
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_ !?
Is there really nothing better than sudo find / <something to show
files with uid or gid perms> and try to figure out which of those
program are not necessary?
$ sudo crontab -l
...
47 4 * * * (apt update >> apt-update.log 2>/dev/null) && \
(apt list --upgradable 2>/dev/null |\
egrep -v '^Listing' >| /etc/motd)
A more proactive endeavor would be to document known best practices
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.
so apparently somebody else has done a threat analysis and decided
apparmor is the appropriate mitigation strategy?
I disagree. I don't think I'm qualified to make an adequate threat
analysis for a Debian system and yet
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".
oof. Are there instructions somewhere on how to make Debian secure by default?
Thanks, Lee
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.
[1] https://xkcd.com/1200/
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.
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. [...]
"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).
Security, as Bruce Schneier [1] says, is a process. Not a product.
On 2024-03-28, Greg Wooledge <greg@wooledge.org> 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.
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?
Hello,
On Thu, Mar 28, 2024 at 05:47:44PM -0000, Curt wrote:
On 2024-03-28, Greg Wooledge <greg@wooledge.org> 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.)
He's actually referring to credentials stored externally being
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
Andy Smith <andy@strugglers.net> 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 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.
On 2024-03-29, Andy Smith <andy@strugglers.net> wrote:
It makes no fucking difference, because your important data is elsewhere >> and completely out of your control.
I WAS going to gently suggest that you have a lie down in a cool,
shaded room, but which of us had this on our 2024 bingo card?
This is not a rational response or argument to the reality of the
situation. You are not in control of your essential data if you are integrated into modern society. I have demonstrated my point with the
French health-care system. If you have a counter-argument, I'd love to
hear it. But you manifestly do not, and resort childish retorts that
mean nothing.
Andy Smith <andy@strugglers.net> 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?
On 2024-03-28, tomas@tuxteam.de <tomas@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.
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.
O-o, is there any simple test to check if I have infected version or
not?
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
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.
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
On Sun, Mar 31, 2024 at 07:00:50PM +0000, Andy Smith wrote:Does this mean its now safe to update our bookworm installs?
Hello,The fix has also been made to stable and oldstable: https://lists.debian.org/debian-security-announce/2024/msg00058.html
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
Regards,
-Roberto
On 3/31/24 15:26, Roberto C. Snchez wrote:
https://lists.debian.org/debian-security-announce/2024/msg00058.htmlDoes this mean its now safe to update our bookworm installs?
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.htmlDoes 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
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.
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.
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.
* 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.
Hi,
On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote:
From what I have read, lzma is not a direct dependency of openssh. It turns out that it lzma is a dependency of libsystemd and that
relationship affected openssh.
Jacob Bachmeyer in analysis (https://lists.gnu.org/archive/html/automake/2024-04/msg00000.html)
says:
Lastly on this topic, some of the blame for this needs to fall on the systemd maintainers [...]
In my view a great example of the "people other than me just need to
get good" fallacy merged with the group of people predisposed to
hate systemd.
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.
* On 2024 01 Apr 23:41 -0500, tomas@tuxteam.de wrote:
This pattern has been seen in other contexts. Here [1] is a good review
of "supply chain attacks" [...]
If you have Rust and Go in mind,
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:
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.
Hi,
On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote:
From what I have read, lzma is not a direct dependency of openssh. It turns out that it lzma is a dependency of libsystemd and that
relationship affected openssh.
Jacob Bachmeyer in analysis (https://lists.gnu.org/archive/html/automake/2024-04/msg00000.html)
says:
Lastly on this topic, some of the blame for this needs to fall on the systemd maintainers and their "katamari" architecture. There is no good reason for notifications of daemon startup to pull in liblzma, but using libsystemd for that purpose does exactly that, and ended up getting xz-utils targeted as a means of getting to sshd without the OpenSSH maintainers noticing.
End quote.
In my view a great example of the "people other than me just need to
get good" fallacy merged with the group of people predisposed to
hate systemd.
It could have been any direct or indirect dependency of sshd here.
I'm quite sure almost none of them have the required resources and
processes to detect something like this.
I think anyone buying into systemd-blaming here needs to have a good
hard look at their biases. Which is another part of this massive
social problem. It's such a distraction. And here we are in a thread
that started with a bug in a 30+ year old setgid binary.
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 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.
On Mon, 1 Apr 2024 19:00:29 +0000
Andy Smith <andy@strugglers.net> wrote:
In my view a great example of the "people other than me just need to
get good" fallacy merged with the group of people predisposed to
hate systemd.
It could have been any direct or indirect dependency of sshd here.
I'm quite sure almost none of them have the required resources and processes to detect something like this.
Easy, now. No-one is attacking systemd, and I don't think anyone wanted
to start a systemd war. This could also have happened under System V initialization.
I have no doubt that this sort of thing has happened in the past, and I
fully expect it will happen again in the future. However, the defect
has been caught and repaired. The system for dealing with
vulnerabilities is working, if not perfectly. The question now is: what lessons can we learn from it.
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.
"enough eyes make all bugs shallow"
doesn't hold true unless the process is actually providing those
eyes.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 154:54:35 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,848 |