Re: making 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 -- underground experts united https://dataswamp.org/~incal
Re: making Debian secure by default
On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote: > I just saw this advisory > Escape sequence injection in util-linux wall (CVE-2024-28085) > https://seclists.org/fulldisclosure/2024/Mar/35 > where they're talking about grabbing other users sudo password. Are there any users logged in to your computer you dont't trust? Thought so. Relax. Security means first and foremost understanding the threat. Randomly reaching into the CVE box will most probably keep you from actually working on your real issues. E.g. your browser. Or your social media account. Cheers [1] https://xkcd.com/1200/ -- t signature.asc Description: PGP signature
Re: making Debian secure by default
On Wed, Mar 27, 2024 at 10:22 PM Andy Smith wrote: > > Hello, > > On Thu, Mar 28, 2024 at 07:37:13AM +0800, jeremy ardley wrote: > > Some distros, like Debian, do not seem to have a command like > > command-not-found by default. > > […] > > > Which implies that Debian is secure by default against this particular > > exploit > > I suspect if OP is worried about users potentially falling for a > fake sudo password prompt then OP is probably not happy about all > the other possibilities around putting arbitrary text on a user's > terminal. Yes, that. I'm not thrilled with the idea of anybody putting arbitrary text on someone else's terminal; what really concerns me is the ability to send control codes. Wasn't there some exploit that involved injecting text and a control code that acted like a carriage return? Lee
Re: making Debian secure by default
On Wed, Mar 27, 2024 at 10:07 PM Andy Smith wrote: > > Hi, > > On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote: > > I just saw this advisory > > Escape sequence injection in util-linux wall (CVE-2024-28085) > > https://seclists.org/fulldisclosure/2024/Mar/35 > > where they're talking about grabbing other users sudo password. > > It doesn't work by default on Debian as it relies on > command-not-found automatically running on the user's input. > command-not-found can be installed, however… > > > oof. Are there instructions somewhere on how to make Debian secure by > > default? > > Between the fact that "secure" means different things to different > people and that this advisory was only released a few hours ago, I > don't think you can reasonably expect documentation to already be > published for your standard of "secure". You snipped the bit from the man page about users becoming more more conscious of various security risks & removing write access by default. Considering how long it takes something to migrate into stable I'm guessing that man page is pretty old. So I don't think it's unreasonable to expect some kind of secure by default installation option. > There is a general push to get rid of setuid/setgid binaries. A lot > of "hardening" guides will suggest looking for setuid/setgid > binaries and deciding if you really need them. The problem with that is how many users are knowledgeable enough to know if something is necessary or not? > As you've never heard of "mesg" and probably don't use "wall" I > doubt you will have any issues chmod 0 /usr/bin/wall and then > setting it immutable¹ with chattr +i. I suppose that's one way. I'd rather uninstall it. > You could put a call to "mesg n" into a file in /etc/profile.d so > that all users execute it. Good idea: $ ls -l /etc/profile.d/disable_mesg.sh -rw-r--r-- 1 root root 383 Mar 28 00:15 /etc/profile.d/disable_mesg.sh $ cat /etc/profile.d/disable_mesg.sh # man mesg #... # Traditionally, write access is allowed by default. However, as users # become more conscious of various security risks, there is a trend to # remove write access by default, at least for the primary login shell. # To make sure your ttys are set the way you want them to be set, mesg # should be executed in your login scripts. /usr/bin/mesg n Then logout / login and.. $ mesg is n Thanks Lee
Re: making Debian secure by default
Hello, On Thu, Mar 28, 2024 at 07:37:13AM +0800, jeremy ardley wrote: > Some distros, like Debian, do not seem to have a command like > command-not-found by default. […] > Which implies that Debian is secure by default against this particular > exploit I suspect if OP is worried about users potentially falling for a fake sudo password prompt then OP is probably not happy about all the other possibilities around putting arbitrary text on a user's terminal. Also as mentioned, command-not-found is packaged in Debian… Getting rid of the "wall" command seems reasonable for most people. It's been almost 30 years since I used it for anything useful. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: making Debian secure by default
On 28/3/24 05:30, Lee wrote: oof. Are there instructions somewhere on how to make Debian secure by default? Further down the advisory is " Some distros, like Debian, do not seem to have a command like command-not-found by default. There does not seem to be a way to leak a users password in this case then, even though we can send escape sequences to them. " Which implies that Debian is secure by default against this particular exploit
Re: making Debian secure by default
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
Re: System hangs at GDM login or a bit later...
On Wed, Mar 27, 2024 at 4:47 PM nimrod wrote: > > I'm having this annoying behaviour from GDM (or something related). > > Quite ofter, after the GDM login screen appears, the host freezes completely: > every input device is unresponsive, no ssh connection from another host is > possible any more, no CTRL+ALT+CANC/F1-F6 is working. > > But the same happens also while I'm typing the username or the password, or > after the login screen disappears because the login was successful, or even a > bit after the dash has appeared at the bottom of the screen. > > Looking at boot.log, the last line before the next boot reads "[ OK ] Started > gdm.service - GNOME Display Manager". > > Looking at syslog instead, the lines are not always the same, but usually > there is something like this: > > 2024-03-27T17:57:25.479168+01:00 SW-GIULIANO > /usr/libexec/gdm-x-session[1831]: (II) Initializing extension RECORD > 2024-03-27T17:57:25.479455+01:00 SW-GIULIANO > /usr/libexec/gdm-x-session[1831]: (II) Initializing extension DPMS > 2024-03-27T17:57:25.479734+01:00 SW-GIULIANO > /usr/libexec/gdm-x-session[1831]: (II) Initializing > ext2024-03-27T17:58:25.469753+01:00 SW-GIULIANO systemd-modules-load[394]: > Inserted module 'lp' > 2024-03-27T17:58:25.469853+01:00 SW-GIULIANO kernel: [ 0.00] microcode: > microcode updated early to revision 0xf4, date = 2023-02-23 > > Please note how the third line suddenly ends with "ext", followed immediately > by the first line written by the next boot sequence. > > The"gdm-x-session" lines above are just the last of a very long list. I can > provide other logs if requested. > > Any hint would be veri appreciated. Can you boot to a previous kernel? Hold SHIFT when the BiOS hands off to Grub to get the Grub menu. If not, then ... maybe a hardware problem. Start with a memory checker. Then move on to disabling the GPU. Jeff
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
Re: debian12: something destroys /etc/network/interfaces at boot
Thank you for your mail. On Wed, Mar 27, 2024 at 12:42 AM Andy Smith wrote: > On Tue, Mar 26, 2024 at 06:33:42PM +0100, Steffen Dettmer wrote: > > I changed a gateway on a remote site using /etc/network/interfaces by > > changing gateway. However, at reboot some old gateway IP reappears. I I also think that there is some Debian packaging rule about one > package not altering the config file of another package unless by > co-operation between the maintainers, so if this does actually turn > out to be Debian there might be bugs to report. Thanks to Pierre-Elliott it became clear that this was caused by a virtualisation platform, so to say "change from outside", and thus I found nothing related "inside". (This is a Proxmox feature to setup containers, and someone made a mistake in the Proxmox configuration;so nothing wrong in Debian at all) Steffen
System hangs at GDM login or a bit later...
Hi, I'm having this annoying behaviour from GDM (or something related). Quite ofter, after the GDM login screen appears, the host freezes completely: every input device is unresponsive, no ssh connection from another host is possible any more, no CTRL+ALT+CANC/F1-F6 is working. But the same happens also while I'm typing the username or the password, or after the login screen disappears because the login was successful, or even a bit after the dash has appeared at the bottom of the screen. Looking at boot.log, the last line before the next boot reads "[ OK ] Started gdm.service - GNOME Display Manager". Looking at syslog instead, the lines are not always the same, but usually there is something like this: 2024-03-27T17:57:25.479168+01:00 SW-GIULIANO /usr/libexec/gdm-x- session[1831]: (II) Initializing extension RECORD 2024-03-27T17:57:25.479455+01:00 SW-GIULIANO /usr/libexec/gdm-x- session[1831]: (II) Initializing extension DPMS 2024-03-27T17:57:25.479734+01:00 SW-GIULIANO /usr/libexec/gdm-x- session[1831]: (II) Initializing ext2024-03-27T17:58:25.469753+01:00 SW-GIULIANO systemd-modules-load[394]: Inserted module 'lp' 2024-03-27T17:58:25.469853+01:00 SW-GIULIANO kernel: [ 0.00] microcode: microcode updated early to revision 0xf4, date = 2023-02-23 Please note how the third line suddenly ends with "ext", followed immediately by the first line written by the next boot sequence. The"gdm-x-session" lines above are just the last of a very long list. I can provide other logs if requested. Any hint would be veri appreciated. Best regards.
