漏洞挖掘经常是没有反馈的, 日常自闭, 在这里记录一下 2022-4-30 写了一个内核漏洞检测工具, 截止到目前水了六个信创操作系统漏洞, 测试仍在继续, 预计一周报一个 写了一个Httpd Fuzz工具, 在lighttpd那里收获三个漏洞, 目前Fuzz目标为nginx, 期间发现nginx自定义内存管理api, 这里使用xxx方法进行适配 对nginx做代码审计, 步入正轨, 着重关注数据流入接口 对内核防御这方面有一些思路, 以后有空再去写 对IOS内核有些兴趣, 正在观望是否入坑 2022-5-12 从一个国产操作系统上水了九个内核洞 写好内核防御思路了，需要再考虑一下是否全面 还是转安卓把

前段时间, 有人声称发现nginx 0day, 并在NginxDay中持续跟进漏洞上报流程, 虽然漏洞确实存在, 但漏洞只存在于一个示例项目, 且漏洞危害较低. 就目前笔者漏洞分析来看, 该行为多少有点花里胡哨, 下面分析一下这个有些鸡肋的漏洞. nginx提供ngx_http_auth_request_module模块用于鉴权, 其功能特点为需要用户自定义实现鉴权api, 并由ngx_http_auth_request_module模块调用 nginx-ldap-auth结合ldap实现鉴权机制, 是一种用户自定义实现鉴权api的示例项目 nginx-ldap-auth功能原理 nginx-ldap-auth关键文件 backend-sample-app.py(处理登录表单), 将user:passwd base64编码后设置Cookie nginx-ldap-auth-daemon.py(结合ldap进行鉴权), 解析http报文中的Cookie/Authorization(有Cookie的情况下鉴权以Cookie为主) ngx_http_auth_request_module模块常用路由 nginx直接向nginx-ldap-auth-daemon.py对应url发起请求, 此时未设置Cookie/Authorization返回401 nginx转发请求至backend-sample-app.py对应url处理登录表单, 并设置Cookie nginx重定向请求至nginx-ldap-auth-daemon.py对应url, 此时存在Cookie, 解析user, passwd, 调用ldap实现鉴权, 成功则返回200 nginx-ldap-auth-daemon.py鉴权分析 从下面鉴权代码可以看出, nginx-ldap-auth-daemon.py使用searchfilter过滤ldap结果, 查找目标登录用户 // ctx['template']默认对应: 'template': ('X-Ldap-Template', '(cn=%(username)s)'), // ctx['user'], ctx['pass']: 从Cookie中解析出的user, passwd searchfilter = ctx['template'] % { 'username': ctx['user'] } .

发表于安全客 1. socket 1.1 sock_create 1.1.1 sock_alloc 1.1.2 inet_create 1.1.2.1 sk_alloc 1.2 sock_map_fd 2. send(运输层) 2.1 import_single_range 2.2 sockfd_lookup_light 2.3 sock_sendmsg 2.4 udp_sendmsg 2.4.1 udp_cmsg_send 2.4.2 TOS 2.4.3 多播/本地广播 2.4.4 检查sock中路由信息是否过期 2.4.5 udp_send_skb 2.4.6 udp_push_pending_frames 3. recv(运输层) 2.1 udp_recvmsg 2.1.1 __skb_recv_udp 2.1.1.1 __skb_try_recv_from_queue 4. IP(网络层) 4.1 ip_cmsg_send 4.2 ip_make_skb 4.2.1 ip_setup_cork 4.2.2 __ip_make_skb 4.3 ip_append_data 4.3.1 __ip_append_data 4.4 ip_send_skb 4.

发表于安全客 KASAN 简述 KASAN是内核用于动态检测内存错误的工具, 简单来说, 数据区域可分为两种:可访问区域，不可访问区域(red_zone).KASAN存在影子内存(shadow memory), 他和正常内存的比例是1:8, 即1byte shadow memory可以代表8bytes 正常内存的可访问性. 128TB(内核正常内存) : 16TB(影子内存) — Documentation/x86/x86_64/mm.rst x86-64 内存布局显示如下: ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory 具体规则(+: byte可访问, -: byte不可访问) 如果1byte shadow memory对应的8bytes 内存都可访问, 则*(shadow memory) == 0 [0] -> [+, +, +, +, +, +, +, +] 如果1byte shadow memory对应的8bytes 内存都不可访问, 则*(shadow memory)为负数 [-1] -> [-, -, -, -, -, -, -, -] 如果1byte shadow memory对应的8bytes 内存中有N bytes可访问, 则*(shadow memory) == N if N = 3 [3] -> [+, +, +, -, -, -, -, -] 实现原理

一些思考, 转眼间, 入坑安全已经两年, 一些心得 2017-2018学年(大一) 2017年进入大学, 学习土木工程专业, 如果没有后面不知缘由的对计算机的热爱, 或许我现在正在朝着桥梁设计建造工程师这个方向迈进 大一的时候喜欢看大国工匠, 内心热血, 总想做些什么, 却发现自己什么都做不了 在通识课上, 第一次接触c语言, 由此写出了人生中的第一行hello world 奇怪的是, 我并没有想着要用c语言去完成什么高大上的项目, 自己告诉自己, 我只是想知道为什么hello world可以被输出 那几个月天天抱着一本厚厚的c语言去研究, 这也算是我的计算机启蒙了吧 但是我还是不知道为什么hello world可以被输出? 再后来对这个问题答案的渴求促使我转专业(即使降级也要转专业), 我不想和这个问题擦肩而过(或许那个时候, 如果有人可以和我说懂这个问题, 我就可以在土木安心呆着了呢 =.=) 接下来就是准备转专业, 开始转专业, 降级转网安成功(顺便遇到了我可爱的女朋友 >。<) 2018-2019学年(还是大一) 带着2017年的问题, 我进入网安, 接触了二进制, 我坚信学习这个方向可以解决我的疑惑 于是2018年的那个秋天, 捧着汇编, 程序员的自我修养度日, 三个月后颤颤巍巍的拿到第一个栈溢出shell, 似懂非懂, 浑浑噩噩, 有拿到shell的喜悦, 但疑惑加深了, 我还是没有解决我的问题, 仿佛陷入死胡同, 而且三个月才学会第一个栈溢出, 这很明显是傻子行为

已投稿于安全客 页表 1.1. 页表查询–以x86_64下的4级页表举例(硬件) 1.1.1. TLB转换 1.1.2. 页表转换 1.1.3. 页表结构cache转换 1.2. 拓展 1.2.1. 普通页表cache 1.2.2. Huge_Page 1.2.3. 页表标志位 伙伴算法(buddy) alloc_pages源码分析 3.1. alloc_pages_current 3.2. __alloc_pages_nodemask 3.2.1. get_page_from_freelist 3.2.2. _alloc_pages_slowpath _free_pages源码分析 4.1. free_unref_page 4.1.1. free_pcppages_bulk 4.2. __free_pages_ok 4.2.1. __free_one_page slub算法 5.