[Security] Malicious SFTP server / HTTP proxy OOM the client: FXP_DATA declared length drives new byte[foo]; ProxyHTTP status line appends unbounded (both verified)

[afldl]

Two verified findings, attacker = malicious (or compromised/MITM'd) server the jsch client talks to. PoC (evil SFTP server + evil HTTP proxy): https://gist.github.com/afldl/e8ff53bdfaa4b783dbe4085b7ff0ec31 . Analysis LLM-assisted, human-verified with real TCP sockets driving the unmodified library. Both sites unchanged on current master (checked 2026-08-24).

1. SFTP: SSH_FXP_DATA declared length is trusted for allocation - ChannelSftp.java:1436

A malicious SFTP server (full SSH2 handshake: curve25519-sha256 + ssh-ed25519 + aes128-ctr) replies to SSH_FXP_READ with a SSH_FXP_DATA whose 4-byte length prefix declares 0x7FFFFFFF while only 17 bytes follow. The InputStream path does rest_byte = new byte[foo] with foo = 0x7FFFFFFF - 17: java -Xmx128m dies with OutOfMemoryError: Java heap space at ChannelSftp$2.read (ChannelSftp.java:1436) (exit 42; server log confirms declared=2147483647, actual=17). An honest declared == actual == 17 reply reads through normally. Every application using sftp.get()/the InputStream API against an untrusted server is affected.

2. ProxyHTTP: response status line accumulates without bound - ProxyHTTP.java:106

A malicious HTTP proxy accepts the CONNECT, then streams non-CR bytes forever; sb.append((char) foo) builds the status line without any length cap: java -Xmx128m dies with OutOfMemoryError at ProxyHTTP.connect (ProxyHTTP.java:106) after consuming ~37 MB. An honest HTTP/1.0 200 + SSH banner connects normally.

Suggested fixes: (1) validate the FXP_DATA length against the remaining packet bytes before allocating (and/or cap at a sane buffer size, falling back to chunked reads); (2) cap the status-line StringBuilder (status lines are bounded by RFC 9110's recommended 8 KB; reply 502/close beyond).

Reproducers (evil servers, Java harnesses, logs) in the gist.

(Note: originally found in com.jcraft/jsch, which appears unmaintained - reporting here since this fork is the actively maintained continuation.)

[norrisjeremy]

Hi @afldl,

Thank you for your submission.
Can you please provide Java code using JSch that when used in conjunction with your Python PoC demonstrate these issues?

Thanks,
Jeremy

[norrisjeremy]

Hi @afldl,

Additionally, for the ProxyHTTP issue: you made a vague reference to RFC 9110 for the suggested fix:

status lines are bounded by RFC 9110's recommended 8 KB; reply 502/close beyond)

Can you please accurately cite where exactly in RFC 9110 this is recommended?

Thanks,
Jeremy

[afldl]

Hi Jeremy,

Java reproducers added (they were part of our verification, I should have included them up front): SftpGetPoc.java and ProxyOomPoc.java are now in the gist. Both drive the real jsch library (not a copy):

• SftpGetPoc.java links JSch, opens a session to the evil SSH/SFTP server (evil_sshd.py, full SSH2 handshake), calls sftp.get(), and reads from the returned InputStream — -Xmx128m dies with java.lang.OutOfMemoryError: Java heap space at ChannelSftp$2.read (ChannelSftp.java:1436) (rest_byte = new byte[foo] with foo = 0x7FFFFFFF-17). Control run against an honest server (declared == actual) reads through normally.
• ProxyOomPoc.java configures session.setProxy(new ProxyHTTP(host, port)), calls session.connect(); the evil proxy (evil_proxy.py) streams non-CR bytes and the client dies with OutOfMemoryError at ProxyHTTP.connect (ProxyHTTP.java:106) (sb.append((char) foo)). Control with an honest HTTP/1.0 200 connects normally.

On the RFC citation — you are right, and thank you for pressing. I verified against the originals: RFC 9110 contains no status-line length recommendation, and I misattributed. The closest real anchor is RFC 9112 §3 (Message Parsing): "Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets" — note this is (a) about the request-line, (b) a minimum-support floor for interoperability, not an upper bound, and RFC 9110 §2.3 explicitly states HTTP places no predefined limit. The 8 KiB figure in my report is deployment practice (nginx large_client_header_buffers default 8k, Apache LimitRequestLine 8190), not an RFC bound. Suggested-fix wording should therefore be: cap the status-line accumulation at a practical size (e.g. 8 KiB) with a clear failure — justified by the 8000-octet interop floor and common deployment caps, not by an RFC limit.

Happy to convert either into a patch with tests if preferred.

[norrisjeremy]

Hi @afldl,

Thank you the additional information.

Thanks,
Jeremy

[norrisjeremy]

Hi @afldl,

Please see #1134 that contains changes that I believe will remedy both issues you have reported.
If you can test and confirm, that would be appreciated.

Thanks,
Jeremy