spectre-meltdown-checker in Fedora and EPEL repositories

 Admin Hints, Fedora, Hardware, News, Security  No Responses »
Feb 152018
 

The recently disclosed Spectre and Meltdown CPU vulnerabilities are some of the most dramatic security issues in the recent computer history. Fortunately even six weeks after public disclosure sophisticated attacks exploiting these vulnerabilities are not yet common to observe. Fortunately, because the hard- and software vendors are still stuggling to provide appropriate fixes.

If you happen to run a Linux system, an excellent tool for tracking your vulnerability as well as the already active mitigation strategies is the spectre-meltdown-checker script originally written and maintained by Stéphane Lesimple.

Within the last month I set myself the target to bring this script to Fedora and EPEL so it can be easily consumed by the Fedora, CentOS and RHEL users. Today it finally happend that the spectre-meltdown-checker package was added to the EPEL repositories after it is already available in the Fedora stable repositories since one week.

On Fedora, all you need to do is:

dnf install spectre-meltdown-checker

After enabling the EPEL repository on CentOS this would be:

yum install spectre-meltdown-checker

The script, which should be run by the root user, will report:

    • If your processor is affected by the different variants of the Spectre and Meltdown vulnerabilities.
    • If your processor microcode tries to mitigate the Spectre vulnerability or if you run a microcode which
      is known to cause stability issues.
    • If your kernel implements the currently known mitigation strategies and if it was compiled with a compiler which is hardening it even more.
    • And eventually if you’re (still) affected by some of the vulnerability variants.

    • On my laptop this currently looks like this (Note, that I’m not running the latest stable Fedora kernel yet):

    # spectre-meltdown-checker                                                                                                                                
Spectre and Meltdown mitigation detection tool v0.33                                                                                                                      
                                                                                                                                                                          
Checking for vulnerabilities on current system                                       
Kernel is Linux 4.14.14-200.fc26.x86_64 #1 SMP Fri Jan 19 13:27:06 UTC 2018 x86_64   
CPU is Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz                                      
                                                                                                                                                                          
Hardware check                            
* Hardware support (CPU microcode) for mitigation techniques                         
  * Indirect Branch Restricted Speculation (IBRS)                                    
    * SPEC_CTRL MSR is available:  YES    
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)                   
  * Indirect Branch Prediction Barrier (IBPB)                                        
    * PRED_CMD MSR is available:  YES     
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)                   
  * Single Thread Indirect Branch Predictors (STIBP)                                                                                                                      
    * SPEC_CTRL MSR is available:  YES    
    * CPU indicates STIBP capability:  YES                                           
  * Enhanced IBRS (IBRS_ALL)              
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO                          
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO                                                                                                           
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  UNKNOWN    
  * CPU microcode is known to cause stability problems:  YES  (Intel CPU Family 6 Model 61 Stepping 4 with microcode 0x28)                                                
                                          
The microcode your CPU is running on is known to cause instability problems,         
such as intempestive reboots or random crashes.                                      
You are advised to either revert to a previous microcode version (that might not have
the mitigations for Spectre), or upgrade to a newer one if available.                

* CPU vulnerability to the three speculative execution attacks variants
  * Vulnerable to Variant 1:  YES 
  * Vulnerable to Variant 2:  YES 
  * Vulnerable to Variant 3:  YES 

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO 
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO 
    * IBRS enabled for User space:  NO 
    * IBPB enabled:  NO 
* Mitigation 2
  * Kernel compiled with retpoline option:  YES 
  * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
  * Retpoline enabled:  YES 
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer

    The script also supports a mode which outputs the result as JSON, so that it can easily be parsed by any compliance or monitoring tool:

    # spectre-meltdown-checker --batch json 2>/dev/null | jq
[
  {
    "NAME": "SPECTRE VARIANT 1",
    "CVE": "CVE-2017-5753",
    "VULNERABLE": true,
    "INFOS": "Vulnerable"
  },
  {
    "NAME": "SPECTRE VARIANT 2",
    "CVE": "CVE-2017-5715",
    "VULNERABLE": false,
    "INFOS": "Mitigation: Full generic retpoline"
  },
  {
    "NAME": "MELTDOWN",
    "CVE": "CVE-2017-5754",
    "VULNERABLE": false,
    "INFOS": "Mitigation: PTI"
  }
]

    For those who are (still) using a Nagios-compatible monitoring system, spectre-meltdown-checker also supports to be run as NRPE check:

    # spectre-meltdown-checker --batch nrpe 2>/dev/null ; echo $?
Vulnerable: CVE-2017-5753
2

    I just mailed to Stéphane and he will soon release version 0.35 with many new features and fixes. As soon as it will be released I’ll submit a package update, so that you’re always up to date with the latest developments.

    “Let’s encrypt” with acme-tiny

     Admin Hints, Open Source, Security  No Responses »
    Sep 052016
     

    Most of my readers must have heard about the “Let’s encrypt” public certificate authority (CA) by now. For those who haven’t: About two years ago, the Internet Security Research Group (ISRG), a public benefit group, supported by the Electronic Frontier Foundation (EFF), the Mozilla Foundation, Cisco, Akamai, the Linux Foundation and many more started the challenge to create a fully trusted public key infrastructure which can be used for free by everyone. Until then, the big commercial certificate authorities such as Comodo, Symantec, GlobalSign or GoDaddy dominated the market of SSL certificates which prevented a wide use of trusted encryption. The major goal of the ISRG is to increase the use of HTTPS for Web sites from then less than 40 percent two years ago to a 100 percent. One step to achieve this, is by providing certificates to everyone for free and the other step, to do this in a fully automated way. For this reason a new protocol called Advanced Certificate Management Environment (ACME) was designed and implemented. Going forward to today: The “Let’s encrypt” CA issued already more than five million certificates and the use of HTTPS is increasing to around 45 percent in June 2016.

    acme-tiny is a small Python script which can be used to submit the certificate request to the “Let’s encrypt” CA. If you’re eligible to request a certificate for this domain you instantly get the certificate back. As such a certificate is only valid for 90 days and the renewal process doesn’t need any user interaction it’s a perfect opportunity for a fully automated setup.

    Since a while I prefer Ansible for all kind of automation tasks. “Let’s encrypt” finally allows me to secure new services, which I spontaneously decide to host on my server via sub-domains. To ease the initial setup and fully automate the renewal process, I wrote an Ansible role ganto.acme_tiny. It will run the following tasks:

    • Generate a new RSA key if none is found for this domain
    • Create a certificate signing request
    • Submit the certificate signing request with help of acme-tiny to the “Let’s encrypt” CA
    • Merge the received certificate with the issuing CA certificate to a certificate chain which then can be configured for various services
    • Restart the affected service to load the new certificate

    In practice, this would look like this:

    • Create a role variable file /etc/ansible/vars/mail.linuxmonk.ch.yml:
      acme_tiny__domain: [ 'mail.linuxmonk.ch', 'smtp.linuxmonk.ch' ]
      acme_tiny__cert_type: [ 'postfix', 'dovecot' ]
    • Make sure the involved service configurations load the certificate and key from the correct location (see ganto.acme_tiny: Service Configuration).
    • Run the playbook with the root user to do the initial setup:

      $ sudo ansible-playbook \
      -e @/etc/ansible/vars/mail.linuxmonk.ch.yml \
      /etc/ansible/playbooks/acme_tiny.yml

    That’s it. Both SMTP and IMAP are now secured with help of a “Let’s encrypt” certificate. To setup automated certificate renewal I only have to add the executed command in a task scheduler such as cron from where it will be executed as unprivileged user acmetiny which was created during the initial playbook run. E.g. in /etc/cron.d/acme_tiny:

    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

@monthly acmetiny /usr/bin/ansible-playbook -e @/etc/ansible/vars/mail.linuxmonk.ch.yml /etc/ansible/playbooks/acme_tiny.yml >/dev/null

    If you became curious and want to have a setup like this yourself, checkout the extensive documentation about the Ansible role at Read the Docs: ganto.acme_tiny.

    This small project was also a good opportunity for me, to integrate all the nice free software-as-a-service offers the Internet is providing for a (Ansible role) developer nowadays:

    • The code “project” is hosted and managed on Github.
    • Every release and pull request is tested via the Travis-CI continuous integration platform. It makes use of the rolespec Ansible role testing framework for which a small test suite has been written.
    • Ansible Galaxy is used as a repository for software distribution.
    • The documentation is written in a pimped version of Markdown, rendered via Sphinx and hosted on Read the Docs from where it can be accessed and downloaded in various formats.

    That’s convenient!