Large SendEnv variables prevent connection

[haarp]

Hello,

the following bug can be observed with Dropbear v2020.81 on armv7l and an OpenSSH_8.9p1 client. It was also observed with older versions of server and client. Unfortunately I'm not able to compile and test a newer version of Dropbear.

When the total size of variables sent by the client via the SendEnv option exceed a certain size, the connection will fail with a Broken pipe. The size seems to be between 30 kB and 40 kB. OpenSSH servers do not have this problem.

Repro:

> export test123=$(dd if=/dev/urandom bs=1000 count=30)
30+0 records in
30+0 records out
30000 bytes (30 kB, 29 KiB) copied, 0.000698384 s, 43.0 MB/s
> ssh -o SendEnv=test123 server
[root@server ~]# yay
[root@server ~]# exit
Connection to server closed.

> export test123=$(dd if=/dev/urandom bs=1000 count=40)
40+0 records in
40+0 records out
40000 bytes (40 kB, 39 KiB) copied, 0.000916885 s, 43.6 MB/s
> ssh -o SendEnv=test123 server
client_loop: send disconnect: Broken pipe

Thanks!

[mkj]

Ah, I could see how that would happen. What is the need for such large environment variables?

[haarp]

What is the need for such large environment variables?

I'm sure there's several use cases. For me, it's convenience. I like to take a few things "with me" when connecting to other machines, such as $LS_COLORS or the contents of my .bashrc. While there's no hard need for these, having to explicitely exclude Dropbear hosts from the SendEnv directive in my SSH config is bothersome.

Cheers!

[mkj]

Fixing this would be tricky. Dropbear allows 35000 bytes per packet (from rfc4253). Increasing that value gives more scope of running out of memory on small devices. A whole packet needs to be kept in memory at once, at least to validate the hmac/aead.

I'll close this, though if someone has ideas how to work around it feel free to reopen.
Note that Dropbear doesn't currently support "env" setting at all, it could be added.

[haarp]

35000 bytes per packet (from rfc4253).

Interesting. I wonder if OpenSSH simply allows larger packets, or somehow tells the client to fragment them. Is there a way to truncate the payload of larger packets during the initial connection without breaking everything? Or warn the user? Crashing with a Broken Pipe makes it hard to diagnose this issue from the user perspective.

Cheers!

[mkj]

Dropbear probably should send a SSH_MSG_DISCONNECT message. It would need a bit of a rework to flush that message out without reading any further incoming traffic.