openssh-7.4p1 (CVE-2016-10009 CVE-2016-10010 CVE-2016-10011 CVE-2016-10012)

[bdubbs@…]

New minor version.

​https://www.openssh.com/releasenotes.html

[Douglas R. Reno]

For whoever gets to this, adding the CVEs.

> ssh-agent(1): Will now refuse to load PKCS#11 modules from paths
> outside a trusted whitelist
> ...
> code execution on the system running the ssh-agent if the
> attacker has control of the forwarded agent-socket (on the host
> running the sshd server) and the ability to write to the filesystem
> of the host running ssh-agent

Use CVE-2016-10009.


> sshd(8): When privilege separation is disabled, forwarded Unix-
> domain sockets would be created by sshd(8) with the privileges of
> 'root'

Use CVE-2016-10010.


> sshd(8): Avoid theoretical leak of host private key material to
> privilege-separated child processes via realloc()

Use CVE-2016-10011.


> sshd(8): The shared memory manager used by pre-authentication
> compression support had a bounds checks that could be elided by
> some optimising compilers
> ...
> potentially allow attacks against the
> privileged monitor process from the sandboxed privilege-separation
> process

Use CVE-2016-10012.


>  * sshd(8): Validate address ranges for AllowUser and DenyUsers
>    directives at configuration load time and refuse to accept invalid
>    ones. It was previously possible to specify invalid CIDR address
>    ranges (e.g. user@127.1.2.3/55) and these would always match,
>    possibly resulting in granting access where it was not intended.

This currently has no CVE ID. We do not know of common scenarios where
an untrusted party is able to specify an invalid CIDR block, but is
unable to specify a valid CIDR block that includes any desired IP
address. A relevant scenario might exist if privileged third-party
software relies, in part, on user input to construct an sshd
configuration file. Even if there were such a scenario, it would
probably be the responsibility of third-party software to validate the
meaning of the CIDR block, and not (for example) accept any string
starting with "10." and ending with "/n" where n is greater than 26.

[bdubbs@…]

Fixed at revision 18105.