[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&focusedCommentId=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-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&focusedCommentId=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] [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&focusedCommentId=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)
