There's a purported PoC exploit that delivers shellcode available on GitHub, but I saw someone comment the link here, and then their comment disappeared on the next refresh.
RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
231–240 of 347 posts
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#232Earlier quoted context omitted.
Does Rust have some invulnerability to race conditions?
It does have invulnerability to data races. However, that guarantee applies only to data types and code in Rust. The dangerous interaction between signals and other functions is outside of what Rust can help with.
There are several crates available which implement the dangerous parts of signal handling safely for you.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#233Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#234From the diff introducing the bug [1], the issue according to the analysis is that the function was refactored from this: void sigdie(const char *fmt,...) { #ifdef DO_LOG_SAFE_IN_SIGHAND va_list args; va_start(args, fmt); do_log(SYSLOG_LEVEL_FATAL, fmt, args); va_end(args); #endif _exit(1); } to this: void sshsigdie(const char *file, const char *func, int line, const char *fmt, ...) { va_list args; va_start(args, fmt…
> It's wild that software nearly the entire world relies on for secure access is maintained by seemingly just two people
obligatory xkcd https://xkcd.com/2347/
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#235From the diff introducing the bug [1], the issue according to the analysis is that the function was refactored from this: void sigdie(const char *fmt,...) { #ifdef DO_LOG_SAFE_IN_SIGHAND va_list args; va_start(args, fmt); do_log(SYSLOG_LEVEL_FATAL, fmt, args); va_end(args); #endif _exit(1); } to this: void sshsigdie(const char *file, const char *func, int line, const char *fmt, ...) { va_list args; va_start(args, fmt…
It's always easy with hindsight to tell how to prevent something. In this case, a comment might have helped why the #ifdef was needed, eg
void CloseAllFromTheHardWay(int firstfd) //Code here must be async-signal-safe! Locks may be in indeterminate state
{
struct rlimit lim;
getrlimit(RLIMIT_NOFILE,&lim);
for (int fd=(lim.rlim_cur == RLIM_INFINITY ? 1024 : lim.rlim_cur);fd>=firstfd;--fd)
close(fd);
}
But I hope that removing the comment or modifying code with a comment about async-signal-safe might have been noticed in review. The code you quoted only has the mention SAFE_IN_SIGHAND to suggest that this code might need to be async-signal-safe
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#236From the diff introducing the bug [1], the issue according to the analysis is that the function was refactored from this: void sigdie(const char *fmt,...) { #ifdef DO_LOG_SAFE_IN_SIGHAND va_list args; va_start(args, fmt); do_log(SYSLOG_LEVEL_FATAL, fmt, args); va_end(args); #endif _exit(1); } to this: void sshsigdie(const char *file, const char *func, int line, const char *fmt, ...) { va_list args; va_start(args, fmt…
It's always easy with hindsight to tell how to prevent something. In this case, a comment might have helped why the #ifdef was needed, eg void CloseAllFromTheHardWay(int firstfd) //Code here must be async-signal-safe! Locks may be in indeterminate state { struct rlimit lim; getrlimit(RLIMIT_NOFILE,&lim); for (int fd=(lim.rlim_cur == RLIM_INFINITY ? 1024 : lim.rlim_cur);fd>=firstfd;--fd) close(fd); } Although to be ho…
The ifdef name was a big clue! "SIGHAND" is short for signal handler. Sure, there is an implicit connection here from "signal handler" to "all code must be async signal safe," but that association is pretty well known to most openssh authors and code reviewers. Oh well, mistakes happen.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#237Interestingly, the RCE fix was "smuggled" in public almost a month ago. When PerSourcePenalties are enabled, sshd(8) will monitor the exit status of its child pre-auth session processes. Through the exit status, it can observe situations where the session did not authenticate as expected. These conditions include when the client repeatedly attempted authentication unsucessfully (possibly indicating an attack against…
Has this fix been pushed to / pulled by distributions yet?
Fedora: not yet.
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2024-6387 (tracking task)
https://bugzilla.redhat.com/show_bug.cgi?id=2294905 (Fedora 39 issue)
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#238Earlier quoted context omitted.
> Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). AMD to the rescue - fortunately they decided to leave the take-a-way and prefetch-type-3 vulnerability unpatched, and continue to recommend that the KPTI mitigations be disabled by default due to performance costs. This breaks ASLR on all these systems…
What are you talking about ? My early-2022 ryzen 5625U shows: Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Not affected Mds: Not affected Meltdown: Not affected Mmio stale data: Not affected Reg file data sampling: Not affected Retbleed: Not affected Spec rstack overflow: Vulnerable: Safe RET, no microcode Spec store bypass: Mitigation; Speculative Store Bypass disabled via pr…
these are the tests you need to run: https://github.com/amdprefetch/amd-prefetch-attacks/blob/mas...
you probably want to do `export WITH_TLB_EVICT=1` before you make, then run ./kaslr. The power stuff is patched (by removing the RAPL power interface) but there is still timing differences visible on my 5700G and the WITH_TLB_EVICT makes this fairly obvious/consistent:
```csv
452,0xffffffffb8000000,92,82,220
453,0xffffffffb8200000,94,82,835
454,0xffffffffb8400000,110,94,487
455,0xffffffffb8600000,83,75,114
456,0xffffffffb8800000,83,75,131
457,0xffffffffb8a00000,109,92,484
458,0xffffffffb8c00000,92,82,172
459,0xffffffffb8e00000,110,94,499
460,0xffffffffb9000000,92,82,155
```
those timing differences are the presence/nonpresence of kernel pages in the TLB, those are the KASLR pages, they’re slower when the TLB eviction happens because of the extra bookkeeping.
then we have the stack protector canary on the last couple pages of course:
```csv
512,0xffffffffbf800000,91,82,155
513,0xffffffffbfa00000,92,82,147
514,0xffffffffbfc00000,92,82,151
515,0xffffffffbfe00000,91,82,137
516,0xffffffffc0000000,112,94,598
517,0xffffffffc0200000,110,94,544
518,0xffffffffc0400000,110,94,260
519,0xffffffffc0600000,110,94,638
```
edit: the 4 pages at the end of the memory space are very consistent between tests and across reboots, and the higher lookup time goes away if you set the kernel boot option "pti=on" manually at startup, that’s the insecure behavior as described in the paper.
log with pti=on kernel option: https://pastebin.com/GK5KfsYd
```csv
513,0xffffffffbfa00000,92,82,147
514,0xffffffffbfc00000,92,82,123
515,0xffffffffbfe00000,92,82,141
516,0xffffffffc0000000,91,82,134
517,0xffffffffc0200000,91,82,140
518,0xffffffffc0400000,91,82,151
519,0xffffffffc0600000,91,82,141
```
environment: ubuntu 22.04.4 live-usb, 5700G, b550i aorus pro ax latest bios
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#239Earlier quoted context omitted.
What benefits does port knocking give over and above a simple VPN? They're both additional layers of authentication, except a VPN seems much more rigorous and brings potentially other benefits. In a world where tailscale etc. have made quality VPNs trivial to implement, why would I both with port knocking?
Are you assuming that VPNs are more secure than ssh?
Yes, inherently yes. Because they have a lot less features than SSH.
It's in the name; Secure Shell, vs. Virtual Private Network. One of them has to deal with users, authentication, shells, chroots. The other mostly deals with the network stack and encryption.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#240Earlier quoted context omitted.
I'm kind of surprised advocating calling any syscall other than signal to add the handler back again. It's been a long time since I looked at example code, but back in the mid 90s, everything I saw (and so informed my habits) just set a flag, listened to the signal again if it was something like SIGUSR1 and then you'd pick up the flag on the next iteration of your main loop. Maybe that's also because I think of a sig…
This isn't the case for OpenSSH but because a lot of environments (essentially all managed runtimes) actually do this transparently for you when you register a signal "handler" it might be that less people are aware that actual signal handlers require a ton of care. On the other hand "you can't even call strcmp in a signal handler or you'll randomly corrupt program state" used to be a favorite among practicing C lawy…
Why can't you call strcmp? I think a general practice of "only call functions that are explicitly blessed as async-signal-safe" is a good idea, which means not calling strcmp as it hasn't been blessed, but surely it doesn't touch any global (or per-thread) state so how can it corrupt program state?
Update: according to https://man7.org/linux/man-pages/man7/signal-safety.7.html strcmp() actually is async-signal-safe as of POSIX.1-2008 TC2.