|
|
[原创] CVE-2019-2025(水滴) 漏洞利用
这个其实不一定,你先用一个小的size去完成置1,然后后面申请一个大的size内存,让这个大内存横跨两个page,自然就可以down_write了。后面的这个page就是要分配的,好像和shrink没啥关系。 |
|
|
[原创] CVE-2019-2025(水滴) 漏洞利用
很费劲的看了这个洞的利用,试了很多次类似楼主的做法,没成功过,在我的设备上,内核里面打了日志粗略的算了算,binder_buffer的alloc和free操作花费的时间基本上都是us级别的,而从内核日志上观察到alloc线程开始做alloc以及free线程开始做free操作,这俩操作的时间差别是ms级别,所以,时间上很难做调整,race起来应该很困难。不过,最后还是找到了一个方法可以把alloc线程做alloc的时间扩大到几十s,因为alloc期间有的情况下会争用mm->mmap_sem,可以用mmap不断争用这个锁,直接把alloc操作扩大到几十s,随后再去搞free,成功率会高很多。 |
|
|
[分享]关于 fuzz 的 一点总结
niubi |
|
|
|
|
|
|
|
|
[讨论]水滴-cve-2019-2025的利用
958K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5&6x3W2)9J5k6e0p5$3z5q4)9J5k6e0b7K6i4K6u0W2x3e0j5#2i4K6u0r3K9q4)9J5k6h3S2@1L8h3H3`. |
|
|
[讨论]水滴-cve-2019-2025的利用
我猜这里mutex和其他地方的锁可能会是一个点,进程被mutex挂起来,然后后面的调度部分,是不是能有一些东西。。 google的说明:66cK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6T1N6h3N6K6i4K6u0W2j5$3S2J5L8$3#2A6N6h3#2Q4x3X3g2G2M7X3N6Q4x3V1k6H3i4K6u0r3M7s2u0G2K9X3g2U0N6q4)9J5k6s2A6W2M7X3!0Q4x3V1k6A6M7%4y4#2k6i4y4Q4x3V1k6V1k6i4c8S2K9h3I4Q4x3@1k6A6k6q4)9K6c8o6p5%4x3U0l9`. 这里面是root权限跑的一个poc,得先做这个binder_become_context_manager的操作,android上没有能力这样搞,因为已经有一个servicemanager了, |
|
|
[讨论]CVE-2018-9568,这个洞看起来问题很大,但是就是不知道怎么用???
我好像有点明白了,如果说可以构造出来这样的case,我顺着这里再瞅瞅,,, |
|
|
[讨论]CVE-2018-9568,这个洞看起来问题很大,但是就是不知道怎么用???
这里怎么会重复分配,错误释放的这一次肯定是把出问题的这个socket给close了,然后引起了free操作,下一次,这块free得到的内存,还是正常被其他的socket拿去用了,为啥会存在两个ipv4 sock使用同一个slab cache? |
|
|
[原创]2017-8890堆喷的一些思考
/proc/slabinfo高版本默认没有,defragmentation我是尝试来做的,多试几次,看看那个数目效率最好 |
|
|
|
|
|
|
|
|
[原创]2017-8890堆喷的一些思考
打打日志,跟跟 |
|
|
|
|
|
[原创]CVE-2017-8890漏洞分析
楼主,你在第一次free之后调用printf、fork这些这么重的函数,占位很大概率会占错啊;而且你喷的时候选的是ipv4的ip_mc_socklist 对象,这个对象虽然size是ok的,但是后续利用起来很难啊,它的next指针不可控,建议从ipv6协议里面找找类似的对象; |
操作理由
RANk
{{ user_info.golds == '' ? 0 : user_info.golds }}
雪币
{{ experience }}
课程经验
{{ score }}
学习收益
{{study_duration_fmt}}
学习时长
基本信息
荣誉称号:
{{ honorary_title }}
勋章
兑换勋章
证书
证书查询 >
能力值