Hacker News Reader

Comment by swid | Hacker News Reader

You can imagine a door that opens if you knock on it just right. For anyone without the secret knock, it appears and functions as a wall. Without the secret knock, there might not even be a way to prove it opens at all.

This is sort of the situation here. xz tries to decode some data before it does anything shady; since it is asymmetric; it can do the decryption without providing the secret encryption key (it has the public counterpart).

The exploit code may never be available, because it is not practical to find the secret key, and it doesn't do anything obviously different if the payload doesn't decrypt successfully. The only way to produce the exploit code would be if the secret key is found somehow; and the only real way for that to happen would be for the people who developed the backdoor to leak it.

View on HN

Private key. In cryptography we distinguish keys which are symmetric (needed by both parties and unavailable to everyone else) as "Secret" keys, with the pair of keys used in public key cryptography identified as the Private key (typically known only to one person/ system/ whatever) and Public key (known to anybody who cares)

Thus, in most of today's systems today your password is a secret. You know your password and so does the system authenticating you. In contrast the crucial key for a web site's HTTPS is private. Visitors don't know this key, the people issuing the certificate don't know it, only the site itself has the key.

I remember this by the lyrics to "The Fly" by the band U2, "They say a secret is something you tell one other person. So I'm telling you, child".

> You know your password and so does the system authenticating you.

Nitpick, but no it shouldn’t.

The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it.

The difference is that there is no two passwords that collide; but there are hashes that may.

And that two equal passwords from two equal users are not necessarily accessible to someone with the hash list because they are modified at rest with salts.

To really nitpick the server does have the password during authentication. The alternate would be a PAKE which is currently quite rare. (But probably should become the standard)

I was going more for shouldn’t. You’re right, but for zero knowledge things like password managers where they specifically do not want your password.

I am aware of PAKEs, and I decided not to waste my time mentioning them because as usual the situation is:

Using a PAKE correctly would be safe, but that sounds like work

Just saying "Use a good password" is no work and you can pretend it's just as safe.

Real world systems using a PAKE are very rare. The most notable is WPA3 (and there are numerous scenarios where it's for nothing until WPA2 is long obsolete). Lots of systems which would use a PAKE if designed by a cryptographer were instead designed by engineers or managers for whom "Ooh, a hash with salt" sounds like a sophisticated modern technical solution rather than a long obsolete one.

More an implementation detail than a conceptual distinction, though.

> Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it.

Nitpick, but the password is submitted as-is by most client applications, and the server hashes the submitted password and compares it with the hash it has (of course, with salting).

> Nitpick, but the password is submitted as-is by most client applications, and the server hashes the submitted password and compares it with the hash it has (of course, with salting).

I never understood why clients are coded this way. It's trivially easy to send the salt to the client and have it do the hashing. Though I guess it doesn't really improve security in a lot of cases, because if you successfully MITM a web app you can just serve a compromised client.

> I never understood why clients are coded this way.

Because it makes things less secure. If it was sufficient to send the hash to the server to authenticate, and the server simply compares the hash sent by the user with the hash in its database, then the hash as actually the password. An attacker doesn't need to know the password anymore, as the hash is sufficient.

Hashing was introduced precisely because some vulnerabilities allow read access to the database. With hashed passwords, the attacker in such a situation has to perform a password guessing attack first to proceed. If it was sufficient to send the hash for authentication, the attacker would not need to guess anything.

> You never submit your password, you submit that hash and they compare it.

That's not true. If that were the case, the hash is now the password and the server stores it in clear text. It defeats the entire purpose of hashing passwords.

Side note: that is (almost) how NTLM authentication works and why pass-the-hash is a thing in Windows networks.

I have often seen the secret component of an asymmetric key pair referred as secret key as well. See libsodium for example. Maybe it's because curve/ed 25519 secrets are 32 random bytes unlike RSA keys which have specific structure which makes them distinct from generic secrets.

It also allows "pk" and "sk" as overly short variable names, an argument developpers are sometimes tempted by!

Absolutely, it's very convenient when working on a whiteboard :)

Private keys are also “secrets” here in the security world.

“Vault secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing”

Your distinction is not shared by the industry so it’s not something helpful to correct people on.

I don't think I can take seriously in this context a quote in which certificates (a type of public document) are also designated "secrets".

Like, sure, they're probably thinking of PKCS#12 files which actually have the private key inside them, not just the certificate, but when they are this sloppy of course they're going to use the wrong words.

I could be wrong, buy my understanding is that it isn't even a door. It simply allows anyone that has a certain private key, to send a payload that the server will execute. This won't produce any audit of someone logging in, you won't see any session etc.

Any Linux with this installed would basically become a bot that can be taken over. Perhaps they could send a payload to make it DDoS another host, or payload to open a shell or payload that would install another backdoor with more functionality, and to draw attention away from this one.

It looks like the exploit path calls system() on attacker supplied input, if the check passes. I don't think we need to go into more detail than "it does whatever the attacker wants to on your computer, as root".

In a way this is really responsible backdoor. In the end this is even less dangerous than most unreported 0-days collected by public and private actors. Absurdly, I would feel reasonably safe with the compromised versions. Somebody selling botnet host would never be so careful to limit collateral damage.

I understand that we may never see the secret knock but shouldn't we have the door and what's behind it now? Doesn't this mean that the code is quite literally too hard to figure out for a human being? It's not like he can send a full new executable binary that he simply executes, then we'd see that the door is e.g the exec() call. Honestly this attempt makes me think that the entire c/c++ language stack and ecosystem is the problem. All these software shenanigans should not be needed in a piece of software like openssh but it's possible because it's written in c/c++.

The payload is simply remote code execution. But we'll never know the secret knock that triggers it, and we can't probe existing servers for the flaw because we don't konw the secret knock.

I imagine that we could in short order build ourselves a modified version of the malware, which contains a different secret knock, one that we know in advance, and then test what would have happened with the malware when the secret knock was given. But this still doesn't help us probe existing servers for the flaw, because those servers aren't running our modified version of the malware, they're running the original malware.

This is literally what the top post link is about. The backdoor functionality has been (roughly) figured out: after decryption and signature verification it passes the payload received in the signing key of the clients authentication certificate to system().

C/C++ is not a problem here because sshd has to run things to open sessions for users.

All analogies are flawed, and we are rapidly approaching the point of madness.

Still, let me try. In this case, someone on the inside of the building looked in a dusty closet and saw a strange pair of hinges on the wall of the closet. Turns out that the wall of the closet is an exterior wall adjoining the alley back behind the building! At least they know which contractor built this part of the building.

Further examination revealed the locking mechanism that keeps the secret door closed until the correct knock is used. But because the lock is based on the deep mathematics of prime numbers, no mere examination of the lock will reveal the pattern of locks that will open it. The best you could do is sit there and try every possible knocking pattern until the door opens, and that would take the rest of your life, plus the rest of the lifetime of the Earth itself as well.

Incidentally, I could write the same exploit in rust or any other safe language; no language can protect against a malicious programmer.

As for detecting use of the back door, that's not entirely out of the question. However it sounds like it would not be as easy as logging every program that sshd calls exec on. But the audit subsystem should notice and record the activity for later use in your post–mortem investigation.

> Honestly this attempt makes me think that the entire c/c++ language stack and ecosystem is the problem. All these software shenanigans should not be needed in a piece of software like openssh but it's possible because it's written in c/c++.

Nothing about this relies on a memory safety exploit. It's hard to figure out because it's a prebuilt binary and it's clever. Unless you meant "all compiled languages" and not C/C++ specifically, it's irrelevant.

The right thing to argue against based on your instinct (no one can figure out what is going on) is: it should be unacceptable for there to be prebuilt binaries committed to the source code.

Nothing here is something that could not be done in other languages. For example in Rust auditing this kind of supply chain attack is even more nightmarish if the project uses crates, as crates often are very small causing the "npm effect".

Another good example is docker images. The way people often build docker images is not that they are build all the way from the bottom. The bottom layer(s) is/are often some arbitrary image from arbitrary source which causes a huge supply chain attack risk.

It's not too hard to figure out. People are figuring it out. If anything is too hard, it's due to obfuscation - not C/C++ shenanigans. As far as I understand from scrolling through these comments, an attacker can send a command that is used with the system() libc call. So the attacker basically has a root shell.

The "stuff behind the door" is conveniently uploaded with the secret knock. It's not there and it will never be because it's remotely executed without getting written down. The attacker does send executable code, singed and encrypted (or only one of them? It does not matter) with their private key. The door checks anything incoming for a match with the public key it has and executes when happy.

C++ has nothing to do with this, it's the dynamic linking mechanism that allows trusted code the things it allows trusted code to do (talking about the hooking that makes the key check possible, not about the execution that comes after - that is even more mundane, code can execute code, it's a von Neumann architecture after all).

Can we stop the ridiculous C++ fearmongering? You can make vulnerable software in any language, and you can do social engineering on any software.

The people who are busy inserting backdoors in all the "rewrite it in rust" projects where anonymous never heard from before new to programming randos rewrite long trusted high security projects in rust would presumably very much like everyone elses attention directed elsewhere.

It's okay, the Cargo Lords promise me that because they require a git-hub account and agreeing to the git-hub terms of service before contributing, everything will be okay.

They pinky-swear.

Reply on news.ycombinator.com