791–800 of 862 posts
Earlier quoted context omitted.
All of this was obfuscated. None of this will be detectable with current static analysis techniques.
IFUNC and landlock could be debugged pretty easily at runtime, just by adding some instrumentation.
It baffles me how such an important package that so many Linux servers use every day is unmaintained by the original author due to insufficient funds. Something gotta change in OSS. I think one solution could be in licenses that force companies/business of certain sizes to pay maintenance fees. One idea from the top of my head.
Earlier quoted context omitted.
I think this would’ve been difficult to catch because the patching of sshd happens during linking, when it’s permissible, and if this is correct then it’s not a master key backdoor, so there is no regular login audit trail. And sshd would of course be allowed to start other processes. A very tight SELinux policy could catch sshd executing something that ain’t a shell but hardening to that degree would be extremely ra…
>A very tight SELinux policy could catch sshd executing something that ain’t a shell but hardening to that degree would be extremely rare I assume. Huh, ssh executes things that aren't shells all the time during normal operation. No? i.e. 'ssh myserver.lan cat /etc/fstab'
Earlier quoted context omitted.
> This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it. Not at all, it is a distro issue because a few distros such as Debian chose to patch openssh to bring in systemd support [1]. Other systemd-based distros like Arch Linux remains unaffected because they don't carry this patch. 1: https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...
Yet Redhat and others applied this patch, as systemd is so incapable of reliably launching processes, that it kept killing sshd without it. What a complete failure of an init system's job, and the patch was applied due to systemd not resolving the issue in another way. This is the problem with systemd. Way, way way too much complexity.
It's not a systemd issue, it's a larger cultural issue with packagers increasing attack surface to make their lives easier.
Earlier quoted context omitted.
Yes, this won't directly protect against an attacker whose goal is to create a botnet, mine some crypto on your dime, etc. However, it will protect against corruption of the O/S itself and, in tandem with other controls, can limit the abilities an attacker has, and ensure things like auditing are still enforced (which can be tied to monitoring, and also used for forensics). Whether it's worth it or not depends on cir…
even easier is to STOP HOSTING SSHD ON IPV4 ON CLEARNET at minimum, ipv6 only if you absolutely must do it (it absolutely cuts the scans way down) better is to only host it on vpn even better is to only activate it with a portknocker, over vpn even better-better is to set up a private ipv6 peer-to-peer cloud and socat/relay to the private ipv6 network (yggdrasil comes to mind, but there's other solutions to darknet)…
If you have password authentication disabled then it shouldn't matter how many thousands of times a day people are scanning and probing sshd. Port knockers, fail2ban, and things of that nature are just security by obscurity that don't materially increase your security posture. If sshd is written correctly and securely it doesn't matter if people are trying to probe your system, if it's not written correctly and securely you're SOL no matter what.
Earlier quoted context omitted.
That's already done, but in this case the attack happened in a glibc ifunc and those run before the patching protection is enabled (since an ifunc has to patch the PLT).
Sounds like libraries should only get to patch themselves. (Some difficulty with this one though. For instance you probably have to ban running arbitrary code at load time, but you should do this anyway because it will stop people from writing C++.)
Earlier quoted context omitted.
That just raises the hurdle for the attacker. The attacker in this case has full control to replace any function within ssh with their own version, and the master process of sshd will always need the ability to fork and still be root on the child process before dropping privileges. I don't see any way around that. They only needed to override one function this time, but if you raise the bar they would just override m…
> The attacker in this case has full control to replace any function within ssh with their own version Not true. They have this ability only for binaries that are linked to liblzma. If sshd were to be decomposed into multiple processes, not all of them would (hopefully) depend on all the libraries that the original sshd depended on.
Earlier quoted context omitted.
I know what replayable means. But even with your explanation of what makes it unreplayable it's not strictly true: you could replay the attack on the server it was originally played against.
Sure. But the interest is in being able to talk to server B to figure out if it's vulnerable; that's impossible, because the attack can't be replayed to it.
Earlier quoted context omitted.
That just raises the hurdle for the attacker. The attacker in this case has full control to replace any function within ssh with their own version, and the master process of sshd will always need the ability to fork and still be root on the child process before dropping privileges. I don't see any way around that. They only needed to override one function this time, but if you raise the bar they would just override m…
I’m highly safety critical systems you have software (and hardware) diversity were multiple pieces of software, developed independently, have to vote on the result. Maybe highly critical pieces of Linux like the login process should be designed the same way. So that two binaries without common dependencies would need to accept the login for the user to get privileges. Exactly how to do it (especially transparently fo…
Earlier quoted context omitted.
Sounds like libraries should only get to patch themselves. (Some difficulty with this one though. For instance you probably have to ban running arbitrary code at load time, but you should do this anyway because it will stop people from writing C++.)
They're all in a single address space, there's nothing you can do to stop one part of a binary patching any other part.