Small Utopia

CVE-2024-0582 是发生在 Linux Kernel 的 io_uring 这一个高性能异步 IO API 中的漏洞，得益于对使用 IORING_REGISTER_PBUF_RING 注册的 ring buffer 在 mmap() 映射的情况下存在可以在释放后仍被使用的 UAF 漏洞，攻击者可以通过该漏洞攻击内核并完成内核提权；该漏洞的 CVSS 分数为 7.8，影响版本包括但不限于 6.4～6.6.5，本文我们选用 6.4 的版本内核源码进行分析。 漏洞分析PBUF_RING Internal我们这里主要关注 io_uring_register 函数中 switch 中与 PBUF_RING 相关的部分 注册：IORING_REGISTER_PBUF_RING对于这个漏洞我们主要关注当 opcode == IORING_REGISTER_PBUF_RING 的情况，该 opcode 意味着注册一个环形缓冲区，其最终会调用到 io_register_pbuf_ring()...

基本信息使用 vmlinux-to-elf 工具转 bzImage 可以得到内核版本信息 6.0.12查看启动脚本： 12345678910111213#!/bin/bashexport KERNEL=.export IMAGE=.echo "start"qemu-system-x86_64 \-m 128M \-kernel $KERNEL/bzImage \-nographic \-append 'console=ttyS0 loglevel=3 oops=panic panic=1 kaslr' \-initrd $IMAGE/rootfs.cpio \-monitor /dev/null \-smp cores=1,threads=1 \-cpu kvm64,smep,smap 开启了 kaslr, smep, smap 保护，查看 /proc/cpuinfo 可以看到开启 kpti 保护。解包文件系统，查看 init...

基本结构io_uring 结构为两个单向环形队列，分为 Submission Queue (SQ) 和 Completion Queue (CQ) ： 内核中使用 io_uring 结构体来保存单个环形队列的 head 和 tail, head 用于出列，tail 用于入列。 1234struct io_uring { u32 head; u32 tail;}; io_uring_sqe 结构体用于表示提交的请求 (Submission Queue Entry)。 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192/* * IO submission data structure (Submission Queue Entry) */struct...

学习 Page-Level 堆风水，学习a3大佬的文章 : -) 保护机制查看 run.sh 脚本内容，发现开启 smep, smap, kpti, kaslr 。 12345678910111213#!/bin/bashqemu-system-x86_64 \ -m 256M \ -cpu kvm64,+smep,+smap \ -smp cores=2,threads=2 \ -kernel bzImage \ -hda ./rootfs.img \ -nographic \ -monitor /dev/null \ -snapshot \ -append "console=ttyS0 root=/dev/sda rw rdinit=/sbin/init kaslr pti=on quiet oops=panic panic=1" \ -no-reboot \ -s 查看 config...

Cross Cache overflow 和 Page-Level Heap Fengshui的例题。参考a3大佬的博客 : -) 保护机制提供了KCONFIG,并且从启动脚本中可以查看到开启了KPTI, SMEP, SMAP保护。 通过KCONFIG查看常见保护开启情况如下： 1234CONFIG_MEMCG_KMEM=yCONFIG_RANDOMIZE_BASE=y # KASLRCONFIG_SLAB_FREELIST_RANDOM=yCONFIG_SLAB_FREELIST_HARDENED=y 题目分析题目在注册设备时创建了kmem_cache，flag为0xDC0，即SLAB_ACCOUNT | SLAB_PANIC,同时开启了CONFIG_MEMCG_KMEM=y，因此申请的kmem_cache为独立的，通过kmem_cache_alloc申请的flag为GFP_KERNEL | __GFP_ZERO。 1234567891011121314151617__int64 init_module(){ castaway_dev = 255; ...

堆溢出例题，参考a3大佬的博客来学习 : -) 保护机制查看启动脚本，开启了KASLR,关闭了KPTI,可以利用ret2usr进行利用。 123456789101112#!/bin/bashexec qemu-system-x86_64 \ -cpu kvm64 \ -m 512 \ -nographic \ -kernel "bzImage" \ -append "console=ttyS0 panic=-1 pti=off kaslr quiet" \ -monitor /dev/null \ -initrd "./rootfs.cpio" \ -net user \ -net nic 源码分析提供了kqueue.c源码，定义了kqueue设备，ops只定义了ioctl操作。该操作为一个堆菜单，包括增删改查等操作。 用户传入的结构体定义如下： 1234567typedef struct{ uint32_t max_entries; //...

该工具是一个用于 rust 内存错误检查的工具，主要是静态分析的方法。跟着 workflow 来就行 : -) 12345678910apt install build-essentialapt-get install m4# fix for unable to find library -lLLVM-11-rust-1.51.0-nightlyrustup toolchain uninstall nightly-2020-12-29-x86_64-unknown-linux-gnurustup toolchain install nightly-2020-12-29 --forcerustup component add rustc-dev llvm-tools-previewcargo cleancargo build --verbose# need to specify lib's pathexport...

文章题目：Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models该工作基于LLM的自动化漏洞挖掘agent实现。通过LLM替代传统的人工代码审计以及逆向分析。 作者发现，通过调整适于现代LLM能力的测试方法，可以显著提高漏洞发现的能力。为实现有效的LLMs漏洞发现评估，作者提出了以下指导原则： 作者在Naptime中也实现了提出的原则，并相较于Meta提出的CyberSecEval2，效果提升了20倍。其方法的得分在”Buffer Overflow”方面从0.05提升到1,在”Advanced Memory Corruption”方面从0.24提升到0.76. Principles1. Space for ReasoningLLM需要进行大量的推理过程。 2. Interactive Environment与程序环境的交互，可以让LLMs调整和纠正其出现的错误。 3. Specialised...

一个项目设备，记录下获取到固件的过程。 尝试1：串口提取（失败）首先通过USB2TTL拿到了U-Boot shell。命令里没有md等命令，尝试通过设置bootargs环境变量方式来。 尝试2：mtd 挂载（失败）还考虑使用 mtd 挂载的方式来读取，不过经过尝试，该方法仅适用于 ubi.img 没有错误的情况，否则会在 ubi attach 的时候报错。对应的 flash 芯片为 GD5F2GQ5UExxG，对应文档链接：https://download.gigadevice.com/Datasheet/DS-00890-GD5F2GQ5UExxG-Rev1.6.pdf可以看到比较重要的数据： 12345# 这四位是 read ID 返回的四个字节Manufacturer ID: 0xC8Device ID: 0x52Byte2 Byte value: noneByte3 Byte value: none 提取到的 bin 文件差不多为 256MB ，共有 2k 个块进行挂载不太行，首先是没有对应的 mtd simulated...

心血来潮有机会把Tenda无线放大器的flash提取出来了，然后在此记录下解包以及安全分析过程 固件提取flash提取就不多说了，用热风枪+编程器一把梭即可拿到flash提取的内存bin文件后，使用binwalk查看，发现了ubi文件，但是直接使用github已有的工具ubi_reader以及ubidump.py都无法成功提取。通过跟着ubidump.py一步步调试发现是两个问题： 该固件的ubi block_size过大，为0x20000。而ubidump.py中定义的太小，无法成功识别到下一个块的magic头 该固件每隔0x800字节都会有0x40字节的padding byte,需要删除掉。解决以上两个问题后，即可看到squashfs文件，将其dump下来。此处贴一下与ubidump.py的diff内容1234567891011121314151617181920212223242526272829303132333435base ❯ diff ubidump.py ubidump.py.bak 296c296< for lnum in...