Junos: Corrupt pam.conf file allows unauthenticated root access

Product Affected:

This issue can affect any product or platform running Junos OS.​​

 
Problem:

When the pam.conf file is corrupted in certain ways, it may allow connection to the device as the root user with no password. This "fail-open" behavior allows an attacker who can specifically modify the file to gain full access to the device.

Note that inadvertent manipulation of the pam.conf by an authorized administrator can also lead to unauthenticated root access to the device. Extreme care should be taken by administrators to avoid modifying pam.conf directly.

While the standalone vulnerability may not be directly exploitable, this issue increases the severity of other attacks that may be chained together to launch a multi-stage advanced attack against the device.

This issue is assigned ​CVE-2015-7751.

Solution:

The following software releases have been updated to resolve this specific issue: Junos OS 12.1X44-D50, 12.1X46-D35, 12.1X47-D25, 12.3R9, 12.3X48-D15, 13.2R7, 13.2X51-D35, 13.3R6, 14.1R5, 14.1X50-D105, 14.1X51-D70, 14.1X53-D25, 14.1X55-D20, 14.2R1, 15.1F2, 15.1R1, 15.1X49-D10, and all subsequent releases.​

This issue was found during internal product security testing.

Juniper SIRT is not aware of any malicious exploitation of this vulnerability.

No other Juniper Networks products or platforms are affected by this issue.

This issue is being tracked as PR 965378 and is visible on the Customer Support website.

KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.​​

Workaround:
​Use access lists or firewall filters to limit CLI access to the router only from trusted hosts.

In addition to the recommendations listed above, it is good security practice to limit the exploitable attack surface of critical infrastructure networking equipment. Use access lists or firewall filters to limit access to the router via SSH or telnet only from trusted, administrative networks or hosts.

VMware Tools unleashed

Prior to this change the ISO file that was downloaded with a new build would be placed on the local datastore of an ESXi host. When applying the VMware Tools to a virtual machine the ISO would be mounted form the local datastore and unmounted after the installation / update was done. Now that the VMware Tools aren’t included with the ESXi builds it is no longer possible to download them through Update Manager. You can now download them directly from the VMware site, but that still means you need to get the ISO ready for use.
Copying the ISO to every ESXi would be a time consuming task and luckily there is an alternative. It is possible to change the location where an ESXi host looks for the VMware Tools. On each host there is a location called the “ProductLocker”, which is a symbolic link that is created when booting a host. This link by default points to a directory on the local datastore. Fortunately for us the location that the symbolic link points to can be changed so that a shared datastore can be used.
First you would need to create a directory on one of your shared datastores like I have done in the screenshot below.

It doesn’t matter what name you give the directory as long as the sub folder has the name “vmtools“. In this folder you will place the new VMware Tools ISO file that you downloaded van the VMware site.
Next you will need to adjust the “UserVars.ProductLockerLocation” setting on each host (you could use host profiles to reduce the manual repetition). You can find this setting within the Advanced settings for the host using the vSphere (web) client. Change this setting so that it contains the path to the directory you created in the previous step. Make note that you do not enter the sub directory that is holding the actual ISO file. The host will automatically search the sub directory within the parent directory you entered.

Now that the configuration is changed we need to apply it. This can be done by either rebooting the host or manually by recreating the symbolic link. For the manual way you need to run commands from the ESXi shell. For ESXi 5.x or later you can use this command:
jumpstart –plugin=libconfigure-locker.so
or
rm /productLocker ln -s /vmfs/volumes/shared_datastore_name/vmware-tools /productLocker
After this you should be able to change to the productlocker directory and find the ISO file you placed on the datastore

No you can install or update the VMware Tools just like you would otherwise.

Open-VM-Tools
Furthermore VMware Tools for Linux (Open-VM-Tools or OVT for short) has been handed over to the Linux community enabeling the adoption of the tools in the Linux kernel main line. This means that customers don’t have to manage the lifecycle of the VMware Tools for certain Linux distributions anymore. Updating OVT will be done through the Linux update mechanic and you can no longer update them using vCenter.
For now the following distributions include OVT:

• Fedora 19 and later releases
• Debian 7.x and later releases
• openSUSE 11.x and later releases
• Recent Ubuntu releases (12.04 LTS, 13.10 and later)
• Red Hat Enterprise Linux 7.0 and later releases
• SUSE Linux Enterprise 12 and later releases
• CentOS 7 and later releases
• Oracle Linux 7 and later