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
* 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
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
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.
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
* 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
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
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
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
* 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.
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
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
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
>
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
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
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
* 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
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
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
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
> >
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
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
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)
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
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
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
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
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
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
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
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,
> >
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,
> 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
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.)
> >
> >
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
On 2024-03-29, Joe wrote:
>
> He's actually referring to credentials stored externally being
Jesus, what a genius.
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
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,
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
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.
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
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
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
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
> >
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
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
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
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
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.
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.
> >>
> >>
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,
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
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
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.
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'
> 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
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
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.
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
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
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
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
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
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
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
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
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
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
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"
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?
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
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
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)
> > >
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
>
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
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
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
"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
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
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
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
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
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
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
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
85 matches
Mail list logo
