-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check inbound unprocessed packet sizes #46
Comments
I do not believe we guard against this, and I believe we should. 1kB is a reasonable default, but we can also make it configurable. |
@Lukasa 1kb for pre-KEX? I think 1KB is a very low amount POST-KEX. |
I was proposing we limit only the banner or version, where length prefixes are absent. Once key exchange has happened packet sizes are guarded by other limits. |
@Lukasa Sorry about the delay, hectic month in terms of freelance projects. In light of the release I visited this issue again, since it's not exactly a big issue to tackel. As part of the same PR I'd suggest we also implement a maximum limit for packets inside of the parser. If someone sends us a 1GB SSH packet right now, I think NIOSSH would just parse the 1GB size and accumulate the 1GB of data before heading into the next step. And to be honest, I can't seem to find the length checks at all. |
Yeah, seems reasonable to me. The RFC requires we tolerate at least 2^15 bytes, so we should make sure to meet that requirement. |
There seem to be SSH-like servers on the internet that behave maliciously, with the intent of repelling malicious connections. They work by sending out an infinite version length or banner. I checked the recent code, but cannot find any length checks or tests. Although I doubt it's a common occurrence, I think it's best to add these checks with tests. I haven't determined a good maximum size yet, however. With some recommendations on that, I'll happily make a PR. I do think separate limits should exist for the pre/post KEX.
The text was updated successfully, but these errors were encountered: