[jira] [Commented] (SSHD-868) Add some protection against maliciously crafted packets
[
https://issues.apache.org/jira/browse/SSHD-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690968#comment-16690968
]
Goldstein Lyor commented on SSHD-868:
-
There are a few more such pitfalls that 1st allocate and then try to loop or
just loop - see [commit
db6e5b5344dcf687ad01a6d7bc94cfa531809d37|https://github.com/apache/mina-sshd/commit/db6e5b5344dcf687ad01a6d7bc94cfa531809d37],
and also [commit
775f34955151d6ec241a1ad3a634c53a87386a64|https://github.com/apache/mina-sshd/commit/775f34955151d6ec241a1ad3a634c53a87386a64]
> Add some protection against maliciously crafted packets
> ---
>
> Key: SSHD-868
> URL: https://issues.apache.org/jira/browse/SSHD-868
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Labels: memory, overflow, security
> Fix For: 2.1.1
>
>
> According to [RFC4256 - section 3.2|https://tools.ietf.org/html/rfc4256]
> {quote}
> The server SHOULD take into consideration that some clients may not
> be able to properly display a long name or prompt field (see next
> section), and limit the lengths of those fields if possible.
> {quote}
> The current code in {{UserAuthKeyboardInteractive#processAuthDataRequest}}
> does not make sure that the number of challenges or the length of each
> challenge is reasonable (not to mention the other packet components).
> Therefore, a maliciously crafted packet can cause out-of-memory errors by
> requesting an extremely large number of responses or sending very large
> challenges.
> It is important to notice that this problem is not limited to the
> {{keyboard-interactive}} protocol but to the entire packet encode/decode
> mechanism since it is a RLE (read-length encoding). Wherever possible we
> should add some reasonable but large enough limitations on the expected size
> of strings/arrays/etc.. being decoded from incoming SSH packets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-863) Add local/remote port forwarding to/from Unix sockets
[ https://issues.apache.org/jira/browse/SSHD-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690936#comment-16690936 ] Björn Kautler commented on SSHD-863: I had a quick look at the specs and it is actually not past of the standard SSH protocol, but an OpenSSH extension. You can find its technical description at point 2.4 of https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL?rev=HEAD. As far as I have seen it basically follows the same rules and flow as normal port forwarding, just with slightly different protocol messages. > Add local/remote port forwarding to/from Unix sockets > - > > Key: SSHD-863 > URL: https://issues.apache.org/jira/browse/SSHD-863 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Björn Kautler >Assignee: Goldstein Lyor >Priority: Minor > > Would be nice if MINA SSHD also supports forwarding sockets, not only ports. > Currently you can only forward from port to port, but SSH now can do from > port to socket, from socket to port, from port to port and from port to > socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-868) Add some protection against maliciously crafted packets
[
https://issues.apache.org/jira/browse/SSHD-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690897#comment-16690897
]
Thomas Wolf commented on SSHD-868:
--
{quote}Perhaps counting the zero-prompt info requests separately and
aborting...{quote}
Ah, I see you did something like this already in [commit
a6dffd5|https://github.com/apache/mina-sshd/commit/a6dffd5].
> Add some protection against maliciously crafted packets
> ---
>
> Key: SSHD-868
> URL: https://issues.apache.org/jira/browse/SSHD-868
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Labels: memory, overflow, security
> Fix For: 2.1.1
>
>
> According to [RFC4256 - section 3.2|https://tools.ietf.org/html/rfc4256]
> {quote}
> The server SHOULD take into consideration that some clients may not
> be able to properly display a long name or prompt field (see next
> section), and limit the lengths of those fields if possible.
> {quote}
> The current code in {{UserAuthKeyboardInteractive#processAuthDataRequest}}
> does not make sure that the number of challenges or the length of each
> challenge is reasonable (not to mention the other packet components).
> Therefore, a maliciously crafted packet can cause out-of-memory errors by
> requesting an extremely large number of responses or sending very large
> challenges.
> It is important to notice that this problem is not limited to the
> {{keyboard-interactive}} protocol but to the entire packet encode/decode
> mechanism since it is a RLE (read-length encoding). Wherever possible we
> should add some reasonable but large enough limitations on the expected size
> of strings/arrays/etc.. being decoded from incoming SSH packets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SSHD-868) Add some protection against maliciously crafted packets
[
https://issues.apache.org/jira/browse/SSHD-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690892#comment-16690892
]
Thomas Wolf edited comment on SSHD-868 at 11/18/18 12:55 PM:
-
Is the length encoding really an issue? Ssh packet length is limited, in Apache
sshd apparently to 256kB (see [{{AbstractSession.decode()}}, line
1007|https://github.com/apache/mina-sshd/blob/0241783/sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java#L1007]).
And for instance {{ByteArrayBuffer.getString(Charset)}} checks that the buffer
does have enough unread bytes available. So if someone sends a packet
containing a bogus string with a length 0x, sshd will throw a buffer
exception, but it won't run into an OOM.
The number of challenges in keyboard-interactive authentication might perhaps
be a problem. A malicious server could just keep on sending zero-prompt info
requests to make the client be stuck. At least until the client-side
authentication timeout kicks in? Perhaps counting the zero-prompt info requests
separately and aborting when that count reaches {{2 * maxTrials}} might be an
idea. I don't see any such count in openssh, though. They seem to count only
the number of inits for keyboard-interactive. See [{{sshconnect2.c}}, lines
1705ff|https://github.com/openssh/openssh-portable/blob/aaed635/sshconnect2.c#L1705].
Looks to me that the Apache sshd way of counting is better.
was (Author: wolft):
Is the length encoding really an issue? Ssh packet length is limited, in Apache
sshd apparently to 256kB (see [{{AbstractSession.decode()}}, line
1007|https://github.com/apache/mina-sshd/blob/0241783/sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java#L1007]).
And for instance {{ByteArrayBuffer.getString(Charset)}} checks that the buffer
does have enough unread bytes available. So if someone sends a packet
containing a bogus string with a length 0x, sshd will throw a buffer
exception, but it won't run into an OOM.
The number of challenges in keyboard-interactive authentication might perhaps
be a problem. A malicious server could just keep on sending zero-prompt info
requests to make the client be stuck. Perhaps counting the zero-prompt info
requests separately and aborting when that count reaches {{2 * maxTrials}}
might be an idea. I don't see any such count in openssh, though. They seem to
count only the number of inits for keyboard-interactive. See
[{{sshconnect2.c}}, lines
1705ff|https://github.com/openssh/openssh-portable/blob/aaed635/sshconnect2.c#L1705].
Looks to me that the Apache sshd way of counting is better.
> Add some protection against maliciously crafted packets
> ---
>
> Key: SSHD-868
> URL: https://issues.apache.org/jira/browse/SSHD-868
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Labels: memory, overflow, security
> Fix For: 2.1.1
>
>
> According to [RFC4256 - section 3.2|https://tools.ietf.org/html/rfc4256]
> {quote}
> The server SHOULD take into consideration that some clients may not
> be able to properly display a long name or prompt field (see next
> section), and limit the lengths of those fields if possible.
> {quote}
> The current code in {{UserAuthKeyboardInteractive#processAuthDataRequest}}
> does not make sure that the number of challenges or the length of each
> challenge is reasonable (not to mention the other packet components).
> Therefore, a maliciously crafted packet can cause out-of-memory errors by
> requesting an extremely large number of responses or sending very large
> challenges.
> It is important to notice that this problem is not limited to the
> {{keyboard-interactive}} protocol but to the entire packet encode/decode
> mechanism since it is a RLE (read-length encoding). Wherever possible we
> should add some reasonable but large enough limitations on the expected size
> of strings/arrays/etc.. being decoded from incoming SSH packets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-868) Add some protection against maliciously crafted packets
[
https://issues.apache.org/jira/browse/SSHD-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690892#comment-16690892
]
Thomas Wolf commented on SSHD-868:
--
Is the length encoding really an issue? Ssh packet length is limited, in Apache
sshd apparently to 256kB (see [{{AbstractSession.decode()}}, line
1007|https://github.com/apache/mina-sshd/blob/0241783/sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java#L1007]).
And for instance {{ByteArrayBuffer.getString(Charset)}} checks that the buffer
does have enough unread bytes available. So if someone sends a packet
containing a bogus string with a length 0x, sshd will throw a buffer
exception, but it won't run into an OOM.
The number of challenges in keyboard-interactive authentication might perhaps
be a problem. A malicious server could just keep on sending zero-prompt info
requests to make the client be stuck. Perhaps counting the zero-prompt info
requests separately and aborting when that count reaches {{2 * maxTrials}}
might be an idea. I don't see any such count in openssh, though. They seem to
count only the number of inits for keyboard-interactive. See
[{{sshconnect2.c}}, lines
1705ff|https://github.com/openssh/openssh-portable/blob/aaed635/sshconnect2.c#L1705].
Looks to me that the Apache sshd way of counting is better.
> Add some protection against maliciously crafted packets
> ---
>
> Key: SSHD-868
> URL: https://issues.apache.org/jira/browse/SSHD-868
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Labels: memory, overflow, security
> Fix For: 2.1.1
>
>
> According to [RFC4256 - section 3.2|https://tools.ietf.org/html/rfc4256]
> {quote}
> The server SHOULD take into consideration that some clients may not
> be able to properly display a long name or prompt field (see next
> section), and limit the lengths of those fields if possible.
> {quote}
> The current code in {{UserAuthKeyboardInteractive#processAuthDataRequest}}
> does not make sure that the number of challenges or the length of each
> challenge is reasonable (not to mention the other packet components).
> Therefore, a maliciously crafted packet can cause out-of-memory errors by
> requesting an extremely large number of responses or sending very large
> challenges.
> It is important to notice that this problem is not limited to the
> {{keyboard-interactive}} protocol but to the entire packet encode/decode
> mechanism since it is a RLE (read-length encoding). Wherever possible we
> should add some reasonable but large enough limitations on the expected size
> of strings/arrays/etc.. being decoded from incoming SSH packets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-865) Use lazy-loading for keys specified in the HostConfigEntry
[
https://issues.apache.org/jira/browse/SSHD-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-865 started by Goldstein Lyor.
---
> Use lazy-loading for keys specified in the HostConfigEntry
> --
>
> Key: SSHD-865
> URL: https://issues.apache.org/jira/browse/SSHD-865
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> Following SSHD-860 key loading occurs lazily - thus encrypted keys password
> is not requested until the key is actually needed. The exception to this rule
> are keys specified as part of a {{HostConfigEntry}} specified in an
> [ssh_config file|http://www.gsp.com/cgi-bin/man.cgi?topic=ssh_config].
> h5. Implementation details
> * Need to change {{SshClient#loadClientIdentities}} to return a
> {{KeyPairProvider}} that is propagated all the way to
> {{SshClient#onConnectOperationComplete}}.
> * The code in {{SshClient#onConnectOperationComplete}} should check after
> {{setupDefaultSessionIdentities}} if there is a non-empty {{KeyPairProvider}}
> propagated and *aggregate* it with any already set such provider on the
> session
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-868) Add some protection against maliciously crafted packets
[
https://issues.apache.org/jira/browse/SSHD-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-868.
-
Resolution: Fixed
Fix Version/s: 2.1.1
> Add some protection against maliciously crafted packets
> ---
>
> Key: SSHD-868
> URL: https://issues.apache.org/jira/browse/SSHD-868
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Labels: memory, overflow, security
> Fix For: 2.1.1
>
>
> According to [RFC4256 - section 3.2|https://tools.ietf.org/html/rfc4256]
> {quote}
> The server SHOULD take into consideration that some clients may not
> be able to properly display a long name or prompt field (see next
> section), and limit the lengths of those fields if possible.
> {quote}
> The current code in {{UserAuthKeyboardInteractive#processAuthDataRequest}}
> does not make sure that the number of challenges or the length of each
> challenge is reasonable (not to mention the other packet components).
> Therefore, a maliciously crafted packet can cause out-of-memory errors by
> requesting an extremely large number of responses or sending very large
> challenges.
> It is important to notice that this problem is not limited to the
> {{keyboard-interactive}} protocol but to the entire packet encode/decode
> mechanism since it is a RLE (read-length encoding). Wherever possible we
> should add some reasonable but large enough limitations on the expected size
> of strings/arrays/etc.. being decoded from incoming SSH packets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
