You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Thomas Wolf (Jira)" <ji...@apache.org> on 2022/05/09 15:03:00 UTC
[jira] [Commented] (SSHD-1266) OpenSSH certificate is not properly encoded when critical options are included
[ https://issues.apache.org/jira/browse/SSHD-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533850#comment-17533850 ]
Thomas Wolf commented on SSHD-1266:
-----------------------------------
When ssh-keygen reads the critical options, it reads the name all right, but the reads the data string as a buffer ([line 2036|https://github.com/openssh/openssh-portable/blob/0086a286ea6bbd11ca9b664ac3bb12b27443d6eb/ssh-keygen.c#L2036]), and then in line 2050 reads a string from that buffer. So for a single critical option, it does _not_ read {{[length-of-string][string bytes]}} followed by {{[length-of-string][string bytes]}} but {{[length-of-string][string bytes]}} followed by {{[length of buffer][[length-of-string][string bytes]]}}. Which means it'll read the first four bytes of what we've written as data as a length, and then bails out.
I had understood the [OpenSSH documentation|https://github.com/openssh/openssh-portable/blob/0086a286ea6bbd11ca9b664ac3bb12b27443d6eb/PROTOCOL.certkeys#L221] differently.
So it looks like we have to double-write the data strings (i.e., pack them in a buffer, then write that buffer), and do the same when reading. Possibly we might have to change {{CriticalOptions}} to store not name-String pairs but name-byte array pairs. The "wrap in buffer" of course would allow for structured data for a critical option, so perhaps that's actually intended and correct.
I'll have to check how these options are read at the place in OpenSSH where they are to be applied.
> OpenSSH certificate is not properly encoded when critical options are included
> ------------------------------------------------------------------------------
>
> Key: SSHD-1266
> URL: https://issues.apache.org/jira/browse/SSHD-1266
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.8.0
> Reporter: Zeljko Vukovic
> Priority: Critical
>
> If critical options are included when OpenSSH certificate is created same can't be read with OpenSSH.
>
> In oder to reproduce issue we can use existing test [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/test/java/org/apache/sshd/certificates/GenerateOpenSSHClientCertificateTest.java#L152] and just add critical options (as in the example bellow)
> {code:java}
> final OpenSshCertificate signedCert = OpenSshCertificateBuilder.userCertificate()
> .serial(0L)
> .publicKey(clientPublicKey)
> .id("user01")
> .principals(Collections.singletonList("user01"))
> .criticalOptions(Arrays.asList(
> new OpenSshCertificate.CertificateOption("force-command", "wget url"),
> new OpenSshCertificate.CertificateOption("source-address", "127.0.0.1/32")))
> .extensions(Arrays.asList(
> new OpenSshCertificate.CertificateOption("permit-X11-forwarding"),
> new OpenSshCertificate.CertificateOption("permit-agent-forwarding"),
> new OpenSshCertificate.CertificateOption("permit-port-forwarding"),
> new OpenSshCertificate.CertificateOption("permit-pty"),
> new OpenSshCertificate.CertificateOption("permit-user-rc")))
> .sign(caKeypair, signatureAlgorithm); {code}
>
> Once we check such certificate we get following error
> {code:java}
> > ssh-keygen -L -f /path/to/cert.pub
> Type: ecdsa-sha2-nistp256-cert-v01@openssh.com user certificate
> Public key: ECDSA-CERT SHA256:0ITcONLKI/H/FNpXZVZMaEYB0STXD4BQNBkSSuDpk5U
> Signing CA: ECDSA SHA256:KPz5LunqQBL9hWJx5eDk11T16anJCn40d/g480PfuKw (using ecdsa-sha2-nistp384)
> Key ID: "user01"
> Serial: 0
> Valid: forever
> Principals:
> user01
> Critical Options:
> show_options: buffer error: string is too large {code}
> and similar for the other cert types(RSA, EC, Ed25519).
> I was tracing this issue and it looks like related to this code [https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/util/buffer/Buffer.java#L840] but I was not able to figure out what exactly.
>
> Interesting is that parsing certificate is working as expected [https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/util/buffer/Buffer.java#L370]
> from code but also even if I create certificate directly with ssh-keygen
> {code:java}
> ssh-keygen -t rsa -b 4096 -f user_ca -C user_ca
> ssh-keygen -f user-key -b 4096 -t rsa
> ssh-keygen -s user_ca -I certN -n user -O source-address="127.0.0.1/32" -O force-command="wget url" -V +10d user-key.pub {code}
>
> [~alex.sherwin@gmail.com] / [~twolf] please if any hints what to check(it looks to me that there is something wrong with encoding certificate option data [https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/util/buffer/Buffer.java#L838-L845] , like these tuples should be written somehow differently) I am more than open to support and create PR.
> This is working as expected for extensions as these are all empty(do not have data) but once we include critical options which have data than there is mentioned failure ([https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.certkeys#L221-L268] ).
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org