On Fri, 26 Sep 2014, Todd Morgan wrote: > At my company we use port forwarding as an alternative to VPN. In previous > releases of openssh (pre 6.0) we could run a script and fetch the thousands > of forwards to our local machine to connect to remote machines. Since > openssh 6.x, whenever we run the same script we get a bufferoverflow error. > > ---- > debug1: channel 4577: new [port listener] > debug1: channel 4578: new [client-session] > debug1: Requesting no-more-sessions@xxxxxxxxxxx > debug1: Entering interactive session. > *** buffer overflow detected ***: ssh terminated I figured this out - there is no actual buffer overflow, but a misguided FD_SET check misfiring. Some background. OpenSSH uses select(2) for fd monitoring. Yes, this is a crappy interface but it is the most portable way to do it and for the vast majority of use absolutely fine. One of the biggest problems with select(2) is that the POSIX-specified API limits the number of file descriptors that can be monitored to FD_SETSIZE (typically 1024). Many Unix variants, including Linux, several commercial Unix and all current BSD allow exceeding this limit by manually allocating the fd_set. OpenSSH has used this for ~15 years. Recently, we enabled FORTIFY_SOURCE to get some libc/toolchain hardening checks. It turns out that one of these is a dumb check in the FD_SET macro that fd < 1024. The check isn't aware of allocated fd_sets or that no overflow actually happens. https://sourceware.org/bugzilla/show_bug.cgi?id=10352 I'm not sure how to disable this check (which is broken) without turning off the rest of FORTIFY_SOURCE (which gives some good hardening). Suggestions welcome. In the meantime, you can disable this check by editing your Makefile (as generated by configure) and removing the -DFORTIFY_SOURCE option from CFLAGS. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
