【立创离大谱BUG之【旋转一分钟】-哔哩哔哩】 https://www.bilibili.com/video/BV1yS421R7g5?p=1
省流: Web 版 LCEDA 属性没写好，把 class 的右边引号和 text 的左边引号弄成 &quote 了

https://vxtwitter.com/IerE043/status/1819272446987632875
CMCC 的 DPI 居然是 Java 写的

AMD 公布严重漏洞：影响数亿个CPU，几乎无法修复

“Sinkclose” 是最近发现的一个重大安全漏洞的名称，该漏洞影响了自 2006 年以来发布的几乎所有 AMD 处理器。此漏洞允许攻击者深入渗透系统，使得检测或删除恶意软件变得极其困难。据Wired报道，这个问题非常严重，在某些情况下，放弃受感染的机器可能比修复它更容易 。

不过，也有好消息：由于该漏洞 18 年来一直未被发现，因此很可能未被利用过。此外，AMD 正在 修补 其平台以保护它们，尽管并非所有受影响的处理器都已收到补丁。

Sinkclose 漏洞允许黑客在 AMD 处理器的系统管理模式 (SMM) 中执行代码，这是一个通常为关键固件操作保留的高权限区域。要利用此漏洞，攻击者必须首先获得系统内核的访问权限，这并不容易，但并非不可能。不过，系统必须已经受到其他攻击的攻击。

一旦获得这种访问权限，Sinkclose 漏洞就会允许犯罪者安装可以逃避标准防病毒工具检测的 bootkit 恶意软件，这种恶意软件在系统中几乎不可见，并且即使在重新安装操作系统后仍能持续存在。

该漏洞利用了 AMD 芯片中名为 TClose 的模糊功能，该功能旨在保持与旧设备的兼容性。通过操纵此功能，研究人员能够重定向处理器以在 SMM 级别执行自己的代码。这种方法很复杂，但为攻击者提供了对系统的深度和持久控制。

—— tom's Hardware

IDEA 2024.2+ 的设置中移除了 Enable New UI 的选项，如需使用老 UI 请安装官方提供的 Classic UI 插件。

#今天又看了啥 #security #Windows #CVE #RCE #IPv6
CVE-2024-38063
Windows TCP/IP Remote Code Execution Vulnerability

CVSS:3.1 9.8 / 8.5
Max Severity: Critical

An unauthenticated attacker could repeatedly send IPv6 packets, that include specially crafted packets, to a Windows machine which could enable remote code execution.

什么？一个整数溢出漏洞，未授权攻击者反复发精心构造的 IPv6 包就能直接 RCE？
而且影响所有受支持的 Windows 版本，包括即将发布的 Windows 11 版本 24H2

Mitigation: Systems are not affected if IPv6 is disabled on the target machine.
退 IPv6 网保平安
微软已在8月13日发布了相关安全更新

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38063

来源：是谁在LINUX内核中开了这个大洞？
https://mp.weixin.qq.com/s/Sr4qIy-AdLhpkus6q1su9w

讨论串：Thread by @evilsocket on Thread Reader App – Thread Reader App https://threadreaderapp.com/thread/1838169889330135132.html

#PSA: 请立即升级 - Firefox 远程代码执行漏洞。

请升级至 Firefox 131.0.2、Firefox ESR 128.3.1 或 Firefox ESR 115.16.1。

mozilla.org/~

CVE: CVE-2024-9680
CVSS: (Critical)

#Firefox

小页页！

写了点奇怪的东西
纯 Java 调用任意 Linux syscall, 仅支持 Android 平台。
https://github.com/cinit/LibcoreSyscall

OpenWrt 宣布重大变更：从 2024 年 11 月起，主开发分支和未来稳定版本（包括即将发布的 24.10 系列）将使用新的包管理器 apk 替代原有的 opkg。这一变化标志着 OpenWrt 平台发展的重要里程碑，opkg 已被弃用并不再包含在 OpenWrt 中。由于这是安装和管理包方式的根本性转变，社区正在 [论坛](https://forum.openwrt.org/t/the-future-is-now-opkg-vs-apk/201164) 中积极讨论新系统的选项和语法。请注意，此变更不影响 23.05 版本，截至 2024 年 11 月 15 日，24.10 分支仍使用 opkg。

https://forum.openwrt.org/t/major-change-notice-new-package-manager/215682

#OpenWrt #PackageManager #TechnologyUpdate

#AIGC

为什么军事书籍和历史书籍都很少配地图，特别是详细的军事地图，这是什么原因？ | 原文

linker: IsEligibleFor16KiBAppCompat
RO 和 RX 挤一起，用于在 16K 页系统上加载 4K 页大小的原生库
https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_phdr_16kib_compat.cpp

Mix! #群友交汇

CVE-2024-11477

Fixed in 7-Zip 24.07
7.8, AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
NVD Published Date: 2024-11-22

7-Zip Zstandard Decompression Integer Underflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the implementation of Zstandard decompression. The issue results from the lack of proper validation of user-supplied data, which can result in an integer underflow before writing to memory. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-24346.

https://nvd.nist.gov/vuln/detail/CVE-2024-11477
https://www.zerodayinitiative.com/advisories/ZDI-24-1532/

在 Android SDK AVD API 23 x86_64 的系统镜像上 android_dlopen_ext 的 ANDROID_DLEXT_USE_LIBRARY_FD 参数无法正常使用

近期在测试 Android 纯内存无文件加载 elf/so 方案的低版本兼容性时，发现在 AVD API 23 (system-images/android-23/google_apis/x86_64) 上 ANDROID_DLEXT_USE_LIBRARY_FD 无法正常工作：尝试 android_dlopen_ext 一个 fd, 得到以下报错

dlopen failed: cannot find "libc.so" from verneed[1] in DT_NEEDED list for "/data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)"

显然这是一个通过 open+unlink 得到的普通 fd.（注：一开始用的 ashmem, 发现此问题后尝试 open+unlink 交叉验证寻找问题）
在 cs.android.com 搜索 "from verneed" 可以发现是 位于 linker 的 VersionTracker::init_verneed 函数。

为排查问题，将 linker 的 __dl_g_ld_debug_verbosity 符号设置为 3, 可以得到以下输出。

I [ 'libmmkv.so' find_loaded_library_by_soname returned false (*candidate=n/a@0x0). Trying harder...]
I name /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted): allocated soinfo @ 0x7f6265742d98
W [ linking /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted) ]
D DEBUG: si->base = 0x7f62678f1000 si->flags = 0x40000000
...
D DEBUG: si->base = 0x7f62678f1000, si->strtab = 0x7f62678f7bd4, si->symtab = 0x7f62678f1330
I [ 'liblog.so' find_loaded_library_by_soname returned false (*candidate=/system/lib64/liblog.so@0x7f6271aa85d8). Trying harder...]
I library "liblog.so" is already loaded under different name/path "/data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)" - will return existing soinfo
I [ 'libz.so' find_loaded_library_by_soname returned false (*candidate=/system/lib64/libz.so@0x7f6271a9f008). Trying harder...]
I library "libz.so" is already loaded under different name/path "/data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)" - will return existing soinfo
I [ 'libm.so' find_loaded_library_by_soname returned false (*candidate=/system/lib64/libm.so@0x7f6271aa21f8). Trying harder...]
I library "libm.so" is already loaded under different name/path "/data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)" - will return existing soinfo
I [ 'libc.so' find_loaded_library_by_soname returned false (*candidate=/system/lib64/libc.so@0x7f6271aa2008). Trying harder...]

I library "libc.so" is already loaded under different name/path "/data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)" - will return existing soinfo
D DEBUG: cannot find "libc.so" from verneed[1] in DT_NEEDED list for "/data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)"
I /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)@0x7f6265742d98 needs to unload /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)@0x7f6265742d98
I /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)@0x7f6265742d98 needs to unload /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)@0x7f6265742d98
I /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)@0x7f6265742d98 needs to unload /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)@0x7f6265742d98
I /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)@0x7f6265742d98 needs to unload libdl.so@0x7f6271b0b6b0
I /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)@0x7f6265742d98 needs to unload /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted)@0x7f6265742d98
I name /data/data/com.example.test.app.syscalldemo/cache/tmpfs-629392441675200/libmmkv.so (deleted): freeing soinfo @ 0x7f6265742d98
I not unloading 'libdl.so' - the binary is flagged with NODELETE

可以看到 "library "libc.so" is already loaded under different name/path", 其位于 linker 的 static soinfo* load_library(int fd, off64_t file_offset, LoadTaskList& load_tasks, const char* name, int rtld_flags, const android_dlextinfo* extinfo) 函数，显然 linker 的 load_library 认为我需要的 libc.so 与正在被加载的 libmmkv.so 是同一个对象。从调用分支结构不难看出 linker 正在加载 DT_NEEDED 的 libc.so, 而此时 extinfo.fd=libmmkv.so, 因而 load_library 直接返回了 libmmkv.so 的 soinfo.

注意到 load_library 有一个 android_dlextinfo* extinfo 参数传入，这个参数来源于 find_libraries->find_library_internal, 通过对比 android-6.0.0_r26 和 android-6.0.0_r41 tag 可以发现，在 android-6.0.0_r26 时，find_libraries 加载 DT_NEEDED 代码如下

// Step 1: load and pre-link all DT_NEEDED libraries in breadth first order.
for (LoadTask::unique_ptr task(load_tasks.pop_front());
    task.get() != nullptr; task.reset(load_tasks.pop_front())) {
  soinfo* si = find_library_internal(load_tasks, task->get_name(), rtld_flags, extinfo);
  if (si == nullptr) {
    return false;
  }
  soinfo* needed_by = task->get_needed_by();
  if (needed_by != nullptr) {
    needed_by->add_child(si);
  }

而 android-6.0.0_r41 修改为了以下

// Step 1: load and pre-link all DT_NEEDED libraries in breadth first order.
for (LoadTask::unique_ptr task(load_tasks.pop_front());
    task.get() != nullptr; task.reset(load_tasks.pop_front())) {
  soinfo* needed_by = task->get_needed_by();
  soinfo* si = find_library_internal(load_tasks, task->get_name(),
                                     rtld_flags, needed_by == nullptr ? extinfo : nullptr);
  if (si == nullptr) {
    return false;
  }
  if (needed_by != nullptr) {
    needed_by->add_child(si);
  }

显然，extinfo 中携带的 ANDROID_DLEXT_USE_LIBRARY_FD 不应被用于其 DT_NEEDED 依赖，而 android-6.0.0_r1-android-6.0.0_r26 由于错误的将包含 ANDROID_DLEXT_USE_LIBRARY_FD 的 extinfo 传入了用于加载依赖的 find_library_internal 导致其依赖无法正常加载或链接。

而 AVD 的 android-23/google_apis/x86_64 系统镜像并未包含此问题的修复，这导致在该系统镜像下任何使用 android_dlopen_ext+ANDROID_DLEXT_USE_LIBRARY_FD 加载具有除 libdl.so 以外依赖的原生库都将失败。

LibcoreSyscall 现已支持在 Android 5.0-15 x86/x64/arm/arm64 纯内存（文件不落地）加载 ELF shared object.
该项目本体仍然是纯 Java 编译的单 dex（无 so 无 assets）
无文件加载 so 的用例可以 参考项目 README