Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 19 Dec 2016 11:21:45 -0500
From: <>
To: <>
CC: <>
Subject: Re: Announce: OpenSSH 7.4 released

Hash: SHA256

> 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@....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.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.