6 ms·

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 k

by swid 3y ago

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.

tialaramex 3y ago
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".
- SV_BubbleTime 3y ago
  > 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.
  - kevincox 3y ago
    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)
    - SV_BubbleTime 3y ago
      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.
      - tialaramex 3y ago
        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.
  - jamwil 3y ago
    More an implementation detail than a conceptual distinction, though.
  - AnonHP 3y ago
    > 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).
    - armada651 3y ago
- forty 3y ago
  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.
  - tux3 3y ago
    It also allows "pk" and "sk" as overly short variable names, an argument developpers are sometimes tempted by!
    - forty 3y ago
      Absolutely, it's very convenient when working on a whiteboard :)
- kortilla 3y ago
  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.
  - tialaramex 3y ago
    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.
takeda 3y ago
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.
Nathanba 3y ago
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++.
- djao 3y ago
  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.
- ivlad 3y ago
  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.
- db48x 3y ago
  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.
cjbprime 3y ago
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".
riedel 3y ago
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.

by swid 3y ago

tialaramex 3y ago

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".

SV_BubbleTime 3y ago
> 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.
- kevincox 3y ago
  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)
  - SV_BubbleTime 3y ago
    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.
    - tialaramex 3y ago
      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.
- jamwil 3y ago
  More an implementation detail than a conceptual distinction, though.
- AnonHP 3y ago
  > 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).
  - armada651 3y ago
forty 3y ago
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.
- tux3 3y ago
  It also allows "pk" and "sk" as overly short variable names, an argument developpers are sometimes tempted by!
  - forty 3y ago
    Absolutely, it's very convenient when working on a whiteboard :)
kortilla 3y ago
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.
- tialaramex 3y ago
  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.

takeda 3y ago

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.

Nathanba 3y ago

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++.

djao 3y ago
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.
ivlad 3y ago
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.
db48x 3y ago
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.

cjbprime 3y ago

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".

riedel 3y ago

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.