spot checking, debian stable, ubuntu 22.04 lts and rhel 7/8/9 all ship pre-9.1 openssh which aren't affected, if that helps put anyone else's mind at ease a bit.
This is already mentioned in a different comment here[1], but for ease of reference, Arch Linux did ship a vulnerable version and released the fix on 2 February[2].
Be very, very concerned with any vulnerabilities that cause crashes. Someone may discover a way to control where the process points to, and now you have a way more serious issue.
For else old folks it would be like WinNuke. Back in the day of dial up your entire PC was front and center on the internet. Windows 95 had a vulnerability that anyone could BSOD you. When it came out basically any IRC or multiplayer interaction you could get BSOD’d by any rando on the internet.
I would be lying if I wasn’t occasionally on the sending end of these at the ripe old age of 12.
When that first showed in theaters in the bay area, people cheered and clapped when she was using Nmap and SSH Nuke. Non tech folks were probably a little confused.
It was a relatively recent exploit, I remember being at an RSA conference when the remote ssh exploit was announced and everyone’s pager started going off and people hustled out of there. Fun times!
I remember people started probing pretty quickly, too, which was a good warning that you couldn’t be complacent about things like that. If memory serves, we’d upgraded most of our servers to only support SSH-2 before this happened and since that included our public shell servers (.edu) nobody broke in to anything but we did have to badger some proprietary vendors for updates to devices which were fortunately on our restricted internal-only network.
Per http://www.openbsd.org, “Only two remote holes in the default install, in a heck of a long time!” I believe, at least one of these, was SSH related.
Yeah, people in the 90s really loved installing redhat 4 (not rhel 4, the old versions) and getting a vulnerable pop2/pop3/imapd running by default after installs. You would get hacked within the hour if not behind firewalls.
Very unfair of OpenBSD (and other security conscious OSes) to not compete on equal terms there.
The JFrog Security Research team gave this vulnerability a Medium severity rating for the following reasons:
A DoS attack that crashes a forked worker process is much less severe than a DoS that crashes an important daemon, but they will both receive a “High” Availability impact CVSS rating.
How is this even considered a DoS at all? You're forking a process and then immediately crashing it. You're only Denying Service to your own connection that you just made.
I agree that this is pretty limited. I think that depends on how expensive it is to create a process: if you could open enough connections or hit something like the audit log frequently enough[1], it might be a decent traffic multiplier when you can't otherwise do something damaging (maybe in a scenario where you get something like a r/o deploy key?).
1. I'm not sure this is very useful but I was thinking that if someone follows one of the security hardening standards, their servers are configured to hang until the audit log buffer can be flushed but you could more easily hit that by failed login requests unless they have something like fail2ban installed.
As you pointed out it's a DOS in the sense that causing a process to fork/crash is much more expensive than a regular denied connection, so it would be easier for an attacker to overload the server using this technique than it would be if they were just making regular denied connections. Also consider that on many systems this would trigger a core dump which will cause a few MB to be written to disk (although you probably can't fill up the disk because in the default configuration most systems are configured to keep either just one core dump or N, where N is some small number like 10).
I think the audit log stuff is a red herring because regular denied connections are already written to the audit log.
You could just open the connections and let them sit without crashing the process. Then those processes and connections will actually be consuming resources instead of crashing and disappearing.
How many resources does that use, however? I’m not sure anything but an embedded device would even notice any of these possibilities. The closest I could come is Ubuntu’s old crash reporter but I thought they hardened that a while back.
On many systems, processes that are rapidly restarting or crashing tend to be throttled; depending on whether cores are enabled you can flood the system with core i/o. In addition, forking servers are often deliberately written to limit the fork frequency (fork bomb prevention).
I assume they mean the latest version available for download as an .iso, since I think that tends to happen around monthly. I agree that this isn't super concerning though, since even installing from that would result in an up-to-date system, and there isn't much reason to ssh to or from the live disk.
> Though remote code execution is theoretically possible, it would require deep-dive research for finding allocation primitives, and even then- will be less impactful because of its security measures.
On the face of it this seems quite lenient. Seems like the only thing holding the gate from preauth ssh rce is the sandbox now, how confident are we about it?
Promoting Rust by attacking C or other legacy languages that do not have equivalent memory safety is simply not constructive dialogue. Whenever the subject comes up concerning C/C++, or vulnerabilities discovered in common software packages someone always shows up to gripe about lack of memory safety in other language and then regurgitate the same litany of Rust vs C/C++ talking points. It gets old and it's not helping win over the developers the Rust community needs if they actually want to re-write the millions of lines code from the many open source projects to fix these problems.
The handful of Rust bros who show up to condemn C/C++ at every opportunity just make the Rust proponents look like a bunch of elitists, which is not fair to Rust or the community.
haha yeah, there is a certain phrasing that just lights up from space... another similarity is the amount of projects written in go that just so happen to be "self contained in a single executable with no shared lib deps!!" (wonder why that is) :)
I’m a huge fan of memory safety but if you’re going to hector other people about open source projects you should either be volunteering code or sending serious money.
“You should rewrite your large C project” is not helpful unless you’re showing up to help.
“Here’s a specific bug you should fix” is different because it’s multiple orders of magnitude less work and doesn’t involve throwing out a ton of perfectly serviceable code.
Obviously actually helping right on the spot can be seen as more valuable, yes. In a perfect world.
In the world we live in, that's just not possible. Can you right every wrong you've ever witnessed?
Some of us see systemic and bigger problems and point those out. In your example it's fair to conclude "writing mission-critical code in C is an unjustified risk". Case in point, in a world where Heartbleed actually happened, that should've led to maintainers admitting that their language of choice isn't the right tool for the job.
As engineers we must be pragmatic. Yet many act like you're attacking their kids if you say "your programming language of choice is ill-suited for writing safe code".
This surprises me to this day, though I guess it really shouldn't. Like you, I imagine a perfect world.
> Some of us see systemic and bigger problems and point those out.
Consider whether this is more useful than saying “you know, you should probably find more time to go to the gym”. Anyone writing C code has heard this by now, and repetition probably isn’t going to help.
What could work is what we have seen successfully with Firefox, Linux, Chrome, Android, etc. where people didn’t demand a massive rewrite but instead showed up to work and picked something small where benefits could be seen quickly. Rust has excellent interoperability so you can do that well but you might run into challenges on projects like OpenSSH which have been ported to all kinds of obscure platforms.
(And, to be clear, I like Rust. It’s just I also understand open source maintainer burnout having had plenty of people suggest huge changes they thought were super important but still not enough that they personally wanted to help.)
I refuse to keep quiet unless I can do somebody's work for them.
Framing the whole thing like "saying C isn't cutting it anymore isn't a useful thing to say" is disingenuous.
As professionals we have to keep ourselves to higher standards. Currently I work in a company where the CTO said "screw you all" and forced a rewrite. And you know what? Recently we released the rewrite and it's going better and better each day.
These things do happen. Informed people with political capital to spend do exist.
It's a shame that the industry at large is mostly just comprised of followers.
(As for gradual rewrites, look at this thread. People are getting worked up just by saying the word "Rust". It's very sad but also kinda hilarious observing [supposed] adults act like that.)
You didn't address the argument. You latched onto an imperfect analogy (and all analogues are imperfect). That tells me everything I need to know: you got no argument. You'll still seek to discredit the other side any way you can though, apparently.
I made arguments in this thread. You ignoring them and insisting on shifting the topic is disingenuous line of arguing.
Spelling it out for you: some safety is better than none. That was the topic. And that people call "cult" whatever they don't like in a very vain attempt to discredit it.
This is why Rust is toxic. This right here. It's unfortunate that an entire language is poisoned by too much dishonest advocacy but here we are. Nobody likes this disingenuous astroturf.
You don't like how I talk -- it's your right. But to ascribe some properties on an entire language and ecosystem, now that is a disingenuous astroturf.
> Not enough libraries for what I had to do at the time. I looked at it.
have you ever considered the same is true for the hundreds of thousands of OSS projects out there that are writing their code in the language they know best and provides a wider range of opportunities?
If the advocacy for safe languages revolves only around _one_ language, it's spam.
It's the same thing of "excuse me sir do you have time to talk about our lord and savior Jesus Christ?"
There are so many imaginary godlike beings, why stop at the one?
> Also you claiming something has "become" cultism does not make it a fact.
spamming without being paid it's cultism.
It's the definition and it's not up for dispute.
> I'd equate you to the people who resisted the use of iron and concrete and claimed you can make tall buildings only out of wood. Anti-progress folks.
False premise.
I've never resisted to Rust, in fact I write Rust code when I need it.
Your argument is deeply flawed.
Because it comes from cultism, not from reasoning.
Whether somebody is spamming you, on a discussion forum that nobody holds a gun at your head to read, is very much up there in the air.
Claiming subjective feelings are facts is kindergarten stuff, I'm really interested how that's not obvious to an adult.
I write in 3 languages lately, Rust included, so stop trying to discredit what you dislike. People will keep pointing out Rust is a better fit for a number of projects and happily there's nothing you can do to stop it. Because it comes from experience and analysis, not cultism.
I upgraded my Mac to Monterey the other day and all of a sudden all of my SSH connections would not work any more. After some digging, I came across a solution where adding
to ~/.ssh/config fixed the issue. I'm wondering if doing this makes me more vulnerable? Or is bad practice somehow? NB: using iTerm2 3.5.0beta9 and Oh My Zsh master (a1c54e0).
Edit: my bad, +ssh-rsa refers to a signature algorithm using SHA1, which should not be used anymore. Target server host keys should be renewed, as told by riolu, thanks to him for pointing it.
On debian-like, remove host keys and run dpkg-configure openssh-server.
On redhat-like, remove host keys and restart sshd.
---------------------------------------------
Not vulnerable, not a bad practice. Newer algorithms are faster (in practice not perceptible, people usually don't need state of the art performance for SSH connections), with smaller keys and probably better algorithms (not subject to side channel attacks, which are still hard to abuse) but RSA is not broken. It may be in a few years with quantum computing but it's still far to be sure.
That change isn't actually about RSA vs. ECC. It's about SHA-1 vs. SHA-2. The default configuration still supports using your existing RSA keys, but with a different hashing algorithm (with the options rsa-sha2-256 and rsa-sha2-512). That configuration change allows use of SHA-1 to continue.
The reason it triggered my question is they had to do something similar to get the exploit to work (add +ssh-rsa to putty). Thanks, though, for the thoughtful reply.
OpenSSH and OpenSSL are completely different projects run by completely different people
Hell, The OpenBSD folks had a "fun" time forking OpenSSL to create "LibreSSL" (before it was promptly ignored by the rest of the open source community unfortunately)
> ...when you insist on writing your codebase in C
It's not really a matter of "insisting". Suppose you start writing an open SSH tool for BSD in 1999. What language do you choose?
Now that it's 2023 and OpenSSH in C is widely used, it's not as if it would be good if it were just abandoned (certainly not good from a security perspective). It makes sense for a team to continue maintaining it, right?
There probably is a better language for an open SSH client. It's not going to write itself, though. This is open source. The interested people need to get together and figure out how to do it.
It's just weird to me to imply the openssh people are doing something wrong when -- absent a time machine -- they clearly are not, and in fact are developing and maintaining a very valuable tool (probably aren't getting rich doing it, either).
If you're truly interested in this endeavour, there's some people who have a pretty good start on it who I think bear mention [1] [2] [3]
For what it's worth "insisting on writing in C" for a large piece of software that's been a fundamental part of the secure internet for over 20 years now is just matter of momentum. We're talking having to redo the entire stack from the kernel to the drivers, ABI and up in a whole new programming language. It's being done, just keep in mind it's an enormous amount of work to get there.
Writing a security critical code base like that is not something everyone could or should do. You do not even know if the one you replied to is even a programmer. Should the start university and study computer engineering and then specialize in cryptography and then finally write the library?
> Writing a security critical code base like that is not something everyone could or should do
I mean... Why not? I know roll your own crypto is bad, but _someone_ has to do it. Might as well be you! Do it in the open, get feedback, attract high skill people to contribute to it and... Tadam! Cool codebase!
I can't shake the feeling that making crypto as this magical thing people show ldnnot dream of is doing a disservice to us all.
Yet the total number of vulnerabilities is smaller than other Rust-implemented programs, because security fundamentally comes down to the engineer, not how many seatbelts there are.
spot checking, debian stable, ubuntu 22.04 lts and rhel 7/8/9 all ship pre-9.1 openssh which aren't affected, if that helps put anyone else's mind at ease a bit.