I think it is unauthenticated from the point of view of SSH’s own authentication. The backdoor has its own credential, but the RCE is accessible if you don’t have an account on the system.
That's the basis for my preferring the term relating to authorization. The two terms have distinct and well-defined meanings in the domain. They're both critical aspects of security but for different reasons.
The distinction between authentication and authorization is important, but only in the context of what’s checking that auth(n/z) is valid.
For something like SSH which has authentication and authorization as features, I would expect to talk about an RCE in that context, and not the backdoor’s auth features.
This backdoor bypasses both authentication (not requiring an account password, authorized key, etc on the target system) as well as authorization (as it doesn’t check a user against any policy for what commands or users can log in).
What makes you say that? SSH, RDP, even hitting a web service are all valid cases of authorized remote code execution. It's not the remote or execution parts that are bad.
I may not have been clear -- I agree that RCE, unqualified, means unauthorized RCE. but then you said there was no such thing as an "authorized" RCE and that's where I beg to differ. Sure, the term isn't used much but it wasn't the clarifying point I wanted to make above, that there is a difference between authenticated and authorized.
The links you point to there are about "RCE attack" which also implies not authorized.
> in the introductory paragraph it reads "unauthenticated, targeted remote code execution ... I believe this means it was unauthorized, not unauthenticated.
You again:
> agree that RCE, unqualified, means unauthorized RCE
So you agree that your "unauthorized" qualification from your orignal post was unwarranted, since all unqualified RCE are unauthorized.
Now if you want to split hairs, you'll say "but the introductory paragraph said unauthenticated, which is qualified RCE, thus I am still right". ok then
