![]() ![]() They should instead be done once encryption is established but session isn't, and a key re-exchange should be initiated once extensions are negotiated. I would argue that the root cause here is extensions being unsafe by default as they're negotiated in plaintext. So you can't manipulate the actual algorithm lists because you have no access to private key material, (if you did you wouldn't have to do this manipulation anyway and could instead just flat out pretend to be one of the participants) but you CAN manipulate extensions since they are not. One interesting bit to notice is why this attack works with but is limited to extensions is because for instance algorithm lists (in the SSH_MSG_KEXINIT message) are included when creating the shared secret to use for the session. ![]() For instance, the AsyncSSH implementation flaws presented. The biggest concern with things like this is not the attack itself, but using it as part of a chain to find other vulnerabilities or cause an escalation to happen. Allow the attacker to manipulate SSH extensions partially.Allow the attacker to deny the use of SSH extensions.Allow the attacker to downgrade connection security in general.What this does NOT do (from my understanding): Can highly recommend reading the original paper, it was refreshingly clear and obviously written for engineers. ![]() I'm not trying to disparage the article or readers, I had some difficulty understand technical details of what this does and does not and I've actually written an implementation of SSH. Some people in these comments are stating that this allows for plaintext observing, which is just not true. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |