Exposed sshd -- looping sshd-auth

[Theo de Raadt]

Havard Eidnes via openssh-unix-dev <openssh-unix-dev at mindrot.org> wrote:

> Hi again,
> 
> it turns out Theo was correct in pointing out the rather
> confusing shenanigans done to read() when "stack smash
> protection" is turned on in NetBSD.
> 
> The reason that one becomes problematic is that each compute unit
> (each file, basically) gets its own "static inline" version of
> read(), and then of course another file's read() isn't equal to
> atomicio.c's version of read(), resulting in the earlier observed
> behaviour.
> 
> The list of functions which get the "buffer overflow protection"
> / "stack smash protection" is listed in the ssp(3) man page, and
> among them are the functions which handle externally-supplied
> data, and read() is among them.
> 
> But write() is not among them (and by extension, neither is
> vwrite()).  So this makes for a relatively simple fix to portably
> avoid the issue: in atomicio.c which now does

I'm going to disagree here.

The netbsd fortify is pretty broken.  ANSI C required Function pointer
equivelance comparison is broken for estimated 40 libc functions.

One instance of this has been found, which didn't have a serious
security impact.

But who's done the legwork to ensure that this problem isn't occuring
elsewhere in OpenSSH?   Or in a library linked into OpenSSH?  Or in
the bigger software ecosystem out there?

Any such bug could deliver a security impact.

Noone has done that legwork.  netbsd fortify is potentially creating
holes.

I think openssh-portable should not pull in this proposed difr,
and should just disable the broken netbsd fortify subsystem.

On netbsd, maybe openssh is linked against some libraries that are
compiled with fortify?  Great........