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 1 of 4  [1] 2 3 4  Next page →

#268557 — making Debian secure 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 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

[toc] | [next] | [standalone]

#268559

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

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

#268562

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

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

#268576

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

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

#268582

On Thu, Mar 28, 2024 at 01:30:32PM +0000, Andy Smith wrote:
> I'm just not sure that you'll find any "hardening" guide that will
> specifically say "disable writing to your terminal as there might be
> a bug in a binary that is setgid tty" before yesterday's reveal that
> there is such a bug in "wall".
> 
> The more general advice to audit every setuid/setgid binary is more
> likely to be present.
[...]
> If the maintainer of util-linux doesn't agree, then the next thing
> I'd try is a bug against the Debian Administrator's Handbook:
> 
>     https://www.debian.org/doc/manuals/debian-handbook/
> 
> This has a chapter on security, so possibly it would be appropriate
> to mention "m,esg n" there.

A more proactive endeavor would be to document known best practices
on the wiki.  A quick search found a couple pages that might serve
as starting points:

    https://wiki.debian.org/SecurityManagement
    https://wiki.debian.org/Hardening  -- says it's for package maintainers

Anyone who is serious about such a project probably has a long road ahead
of them.

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

#268584

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


  

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

#268598

> 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

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

#268611

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

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

#268628

> 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

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

#268629

On Thu, Mar 28, 2024 at 5:17 PM Lee <ler762@gmail.com> 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,
<https://en.wikipedia.org/wiki/Robert_Morris_(cryptographer)>: 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

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

#268585

Hello,

On Thu, Mar 28, 2024 at 11:24:08AM -0400, Greg Wooledge wrote:
> 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.

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

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

#268602

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 +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.
>
> 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

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

#268596

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.

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

#268601

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

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

#268621

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.)

Thanks,
Andy

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

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

#268622

On Fri, 29 Mar 2024 16:53:04 +0000
Andy Smith <andy@strugglers.net> wrote:

> 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.)
> 

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

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

#268623

On 2024-03-29, Joe <joe@jretrading.com> wrote:
>
> He's actually referring to credentials stored externally being

Jesus, what a genius.

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

#268671

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

On Fri, Mar 29, 2024, 12:24 PM Joe <joe@jretrading.com> wrote:

> On Fri, 29 Mar 2024 16:53:04 +0000
> Andy Smith <andy@strugglers.net> wrote:
>
> > 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.)
> >
>
> 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
>
>

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

#268672

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

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

#268673

On Mon, Apr 01, 2024 at 01:45:07AM +0000, 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

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web