By using AWS re:Post, you agree to the Terms of Use

Questions tagged with Linux Provisioning

Sort by most recent
  • 1
  • 12 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Amazon Linux 2 - How can I know if a CVE has been patched?

Hi, My question is - how can we see what CVEs are patched? Where is it recorded if Amazon Linux has patched a particular CVE? There is the security centre here: https://alas.aws.amazon.com/alas2.html, however, that only lists the advisories as far as I can tell - it doesn't say what's patched and what isn't. Is it the case that if an item there shows that there are new packages, we can just assume it's patched in AL? Thanks in advance for any help. **Context** We've had a pen test conducted in our Elastic Beanstalk / Amazon Linux 2 environment. It flagged some potential common vulnerability & exposures (CVEs) - a number of which turned out to be false positives as Amazon Linux maintains its own release of packages. We found that Nginx running in our environment was not version 1.20.0 - vulnerable to CVE-2021-23017, but was version 1.20.0, release 2.amzn.2.0.4 - which according to https://github.com/aws/elastic-beanstalk-roadmap/issues/221 , has been patched against this vulnerability. Having the same version number for each seems like a recipee for disaster. It certainly cost me a few days time trying to look into the issue. ``` [ec2-user@ip-x ~]$ yum info nginx Loaded plugins: extras_suggestions, langpacks, priorities, update-motd 207 packages excluded due to repository priority protections Installed Packages Name : nginx Arch : aarch64 Epoch : 1 Version : 1.20.0 Release : 2.amzn2.0.4 Size : 1.7 M Repo : installed From repo : amzn2extra-nginx1 ``` I've a number of other CVE's that I need to determine if our elastic beanstalk environment is potentially compromised by: If I can just look them up, it would be helpful. ``` OpenSSH <= 8.6 Command Injection Vulnerability CVE-2021-23017 Diffie-Hellman Ephemeral Key Exchange DoS Vulnerability (SSH, D(HE)ater) CVE-2002-20001 nginx <= 1.21.1 Information Disclosure Vulnerability CVE-2013-0337 OpenSSH 6.2 <= 8.7 Privilege Escalation Vulnerability CVE-2021-41617 OpenBSD OpenSSH <= 7.9 Multiple Vulnerabilities CVE-2018-20685, CVE-2019-6109, CVE-2019-6110, CVE-2019-6111 OpenBSD OpenSSH Information Disclosure Vulnerability (CVE-2020-14145) CVE-2020-14145 SSL/TLS: BREACH attack against HTTP compression CVE-2013-3587 OpenSSH 'auth2-gss.c' User Enumeration Vulnerability - Linux CVE-2018-15919 OpenSSH 'sftp-server' Security Bypass Vulnerability (Linux) CVE-2017-15906 OpenSSH < 7.8 User Enumeration Vulnerability - Linux CVE-2018-15473 OpenSSH Information Disclosure Vulnerability (CVE-2016-20012) CVE-2016-20012 ```
1
answers
0
votes
24
views
asked 6 days ago

AuthorizedKeysCommand /usr/share/ec2-instance-connect/eic_run_authorized_keys <username> SHA256:<long hex string> failed, status 22

We use Ubuntu 20.04 (`ami-0c8858c090152d291`) as the basis for a production ecommerce stack, and I need to move users around as part of a handover. In order to do this I am trying to ssh in to the instance using the original ami-configured instance user and AWS generated key, so I can move the user I normally log in as. This fails with the subject error in `/var/log/auth.log`. I have reconfirmed keys and user many times obviously. This appears to be related to [AuthorizedKeysCommand fails on Ubuntu 20.04](https://github.com/widdix/aws-ec2-ssh/issues/157), which blames the package `ec2-instance-connect`. We keep instances up to date, so I suspect this package was installed as part of a post-install security update. The above-linked GitHub thread suggests: ``` # rm /usr/lib/systemd/system/ssh.service.d/ec2-instance-connect.conf # systemctl daemon-reload ``` I have tried the above unsuccessfully. Even after removing `ec2-instance-connect.conf` and issuing either `systemctl daemon-reload` or `kill -s HUP <sshd pid>` the sshd process is *still* running using the `ec2-instance-connect.conf` settings: ``` sshd: /usr/sbin/sshd -D -o AuthorizedKeysCommand /usr/share/ec2-instance-connect/eic_run_authorized_keys %u %f -o AuthorizedKeysCommandUser ec2-instance-connect [listener] 0 of 10-100 startups ``` For obvious reasons I am reluctant to tinker more extensively with the sshd configuration on a production server without hearing from the community. It seems rather questionable (to put it mildly) for a "security update package" to hijack the normal sshd auth process, especially with no well publicized info, only to come to light when I actually have to work on it. The package listing says > Configures ssh daemon to accept EC2 Instance Connect ssh keys -but what it fails to add is "... and may disable other keys". We surely cannot be the first ones to encounter this problem??
0
answers
0
votes
37
views
asked 13 days ago
  • 1
  • 12 / page