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

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

making Debian secure by default

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

Contents

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

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

#268595

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

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

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

#268599

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

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

#268600

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.

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

#268605

On 28 Mar 2024 15:28 -0400, from greg@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?”

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

#268603

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

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

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

#268620

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.

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

#268634

Curt <curty@free.fr> wrote:
> 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.

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.

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

#268609

<tomas@tuxteam.de> 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.

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

#268570

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.

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

#268586

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

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

#268589

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
#
#   TTYGROUP    Login 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.

TTYGROUP    tty
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 ?

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

#268590

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

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

#268606

On 28 Mar 2024 20:30 +0000, from dnomhcir@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?”

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

#268607

Lee <ler762@gmail.com> 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.

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

#268617

On Wed, Mar 27, 2024 at 8:37 PM Lee <ler762@gmail.com> 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
<https://public.cyber.mil/stigs/downloads/?_dl_facet_stigs=unix-linux>.
More generally, for Operating Systems, see
<https://public.cyber.mil/stigs/downloads/?_dl_facet_stigs=operating-systems>.

Jeff

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

#268665

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

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

#268666

On Sun, Mar 31, 2024 at 07:00:50PM +0000, 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

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

#268667

On 3/31/24 15:26, Roberto C. Sánchez wrote:
> On Sun, Mar 31, 2024 at 07:00:50PM +0000, 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

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

#268668

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

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

#268670

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

[toc] | [prev] | [standalone]

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

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

csiph-web