xyz 新文章解释了 PS Vita 首个公开的内核漏洞的原理

BoomerCE · 发表于 2016-8-31 08:56

几个小时之前刚刚发布的文章，非常值得一读

https://blog.xyz.is/2016/vita-netps-ioctl.html

九条樱子 · 发表于 2016-8-31 09:03

没翻译这里基本没人看，不过不得不佩服这些神人，我甚至怀疑他们早就看穿了一切，只是在等索尼犯错，于是3.60的系统更新终于迎来了他们需要的最后一把钥匙。

kz.lj · 发表于 2016-8-31 09:06

好歹daoni

xqterry · 发表于 2016-8-31 09:37

牛逼真好耐性

fantasyzxc · 发表于 2016-8-31 09:43

完美破解了吗到底 3.60表示流口水

宫崎信者 · 发表于 2016-8-31 09:45

PSV现在的情况是即使破解了也懒得开机

九条樱子 · 发表于 2016-8-31 09:46

宫崎信者发表于 2016-8-31 09:45
PSV现在的情况是即使破解了也懒得开机

现在都忙着用维他命dump游戏rom呢。

九条樱子 · 发表于 2016-8-31 09:48

fantasyzxc 发表于 2016-8-31 09:43
完美破解了吗到底 3.60表示流口水

基本完美了，现在都在dump游戏和测试发布，多玩PSV专区一日发帖过万你怕不怕？

宫崎信者 · 发表于 2016-8-31 09:52

九条樱子发表于 2016-8-31 09:46
现在都忙着用维他命dump游戏rom呢。

等像PSP那样有完美破解+海量非官方软件了再说吧 .....更期待的反而是模拟器
希望能有NekoProject PSV版或者ONS之类的玩意

九条樱子 · 发表于 2016-8-31 09:55

宫崎信者发表于 2016-8-31 09:52
等像PSP那样有完美破解+海量非官方软件了再说吧 .....更期待的反而是模拟器
希望能有NekoProject PSV版或 ...

去多玩看看吧，破解得很好了，要求不要太高哦。

eulereld · 发表于 2016-8-31 10:02

九条樱子发表于 2016-8-31 09:55
去多玩看看吧，破解得很好了，要求不要太高哦。

破的聽說也不是全部遊戲？那期待一下接下來的進展也無可厚非吧，畢竟PSP 破解後能玩的花樣多太多，珠玉在前

londo_bell · 发表于 2016-8-31 10:15

看完了，关键在于修改内核SOCKET结构中的函数指针，可见HEAP在FREE之后进一步清零是多么重要

londo_bell · 发表于 2016-8-31 10:20

不过第二个线程要准确地覆盖第一个线程创建的内核SOCKET结构，并修改相应位置的指针，Yifan Lu他们应该尝试了很多次

kabunsan · 发表于 2016-8-31 10:27

能模拟3DS么，有就把吃灰的PSV翻出来 -_-||

—— 来自 HUAWEI GRA-UL10, Android 6.0

nihse · 发表于 2016-8-31 10:50

本来想着如果能拿来玩模拟器倒也不错，
但我买了猴戏机···

cfeng123 · 发表于 2016-8-31 10:50

仔细看了下文章
大概的原理就是利用了VITA的KM_SLEEP标志（当可供申请的内存不足时，会卡住当前线程等内存释放到可申请为止）

然后在 NetBSD里有个BUG，在调用ioctl接口前的判断内存空间是否足够时，判断的是是否有5个0x800 （2048字节）的区块，但申请时，使用的标志位来申请内存最多可以申请0X1FFF(8191字节）。

所以原理就是，
B线程先把内存占用到足够多（有5个0X800，但没有一个完整的0X1FFF的区块）
A线程先申请一个socket，然后传入参数flag申请足够大的内存（大于目前的内存空余量，小于等于8191）于是因为heapmem = malloc(memsz, 0, 8) 内存不足，于是SLEEP了
B线程释放掉A线程申请的socket，然后往对应的那块内存写入破解用的数据再释放掉足够的内存，让A线程可以申请内存
A线程申请到内存，开始调用后续代码，使用原先socket的那块内存空间的函数指针（已经被B线程篡改，指向了破解的函数） crack！

cfeng123 · 发表于 2016-8-31 10:58

本帖最后由 cfeng123 于 2016-8-31 11:01 编辑

londo_bell 发表于 2016-8-31 10:15
看完了，关键在于修改内核SOCKET结构中的函数指针，可见HEAP在FREE之后进一步清零是多么重要 ...

不，并不是进一步清零的问题，其实问题出在了判断和申请不一致（判断是5块0x800，申请是1块1-0X1FFF）
然后杯具的socket没有引用计数再加上vita那个申请不到内存就休眠等到能申请的时候的设定（一般的程序基本上都是alloc失败就返回NULL了）

3个问题只要有一个没有，就不会触发这个问题

雨鱼 · 发表于 2016-8-31 11:13

解释的那么详细是让大法给你永远关掉这个漏洞么

lvcha · 发表于 2016-8-31 11:17

都是码农，差距怎么就那么大呢。。他说的我看都看不懂

cfeng123 · 发表于 2016-8-31 11:19

雨鱼发表于 2016-8-31 11:13
解释的那么详细是让大法给你永远关掉这个漏洞么

3.61已经修复了这个漏洞了

BoomerCE · 发表于 2016-8-31 11:19

雨鱼发表于 2016-8-31 11:13
解释的那么详细是让大法给你永远关掉这个漏洞么

3.61 就已经封上了

londo_bell · 发表于 2016-8-31 11:46

cfeng123 发表于 2016-8-31 10:58
不，并不是进一步清零的问题，其实问题出在了判断和申请不一致（判断是5块0x800，申请是1块1-0X1FFF）
然 ...

overwrite memory with controlled data
For that, I’ve used sceNetControl(int a1, int a2, void *ubuf, int argsize). When passed proper flags, it will allocate a buffer = malloc(argsize) and then copy in user data. At the end of the function, the buffer is freed but it doesn’t really matter because free() doesn’t destroy our data.

With an argsize that matches the socket object size and proper kernel heap spraying, the allocated buffer will have the same address as the freed socket.

倘若FREE后有清零，这步就不成立了

cfeng123 · 发表于 2016-8-31 11:50

londo_bell 发表于 2016-8-31 11:46
倘若FREE后有清零，这步就不成立了

哦，我没注意他们是如何往A线程的socket那块空间释放后重新写数据的。要往这块空间写数据，似乎也要调用有核心权限的函数，那free时没memset就的确是有很大问题了

亚瑟姆·明日野 · 发表于 2016-8-31 11:53

kabunsan 发表于 2016-8-31 10:27
能模拟3DS么，有就把吃灰的PSV翻出来 -_-||

—— 来自 HUAWEI GRA-UL10, Android 6.0

能模拟个NDS就不错了还3DS

雨鱼 · 发表于 2016-8-31 13:54

cfeng123 发表于 2016-8-31 11:19
3.61已经修复了这个漏洞了

目前只能说henkaku不支援3.61而已，并不能说已经封上了

deadbeef · 发表于 2016-8-31 14:12

londo_bell 发表于 2016-8-31 10:15
看完了，关键在于修改内核SOCKET结构中的函数指针，可见HEAP在FREE之后进一步清零是多么重要 ...

跟清0没有任何关系任何一个系统都没有要求内存被释放后还需要清0的
而该BUG之所以只在VITA上发生核心问题是

VITA的SOCKET结构没有引用计数没有引用计数没有引用计数

正是因为没有引用计数才导致出现了UAF漏洞
如果能确保UAF漏洞不出现内存释放后是不会被使用的清0与否根本无关紧要

londo_bell · 发表于 2016-8-31 16:40

deadbeef 发表于 2016-8-31 14:12
跟清0没有任何关系任何一个系统都没有要求内存被释放后还需要清0的
而该BUG之所以只在VITA上发生核心问 ...

见22楼引用，调侃一下罢了，这么激动

deadbeef · 发表于 2016-9-1 01:04

本帖最后由 deadbeef 于 2016-9-1 01:11 编辑

londo_bell 发表于 2016-8-31 16:40
见22楼引用，调侃一下罢了，这么激动

倒不是激动只是觉得有点误导人
没有任何代码会在FREE之前清0内存的更不可能在FREE之后

这里的问题很简单就算真的在FREE前清了0
破解者依旧可以人为造成一个UAF漏洞的发生
结果就是一个全0的SOCKET结构导致内核发生不可预知的崩溃
虽然这个崩溃无法被破解者利用了但是依旧是一个内核态的崩溃

所以问题的核心在于UAF漏洞的产生
而不在于FREE后清不清0

我主要想澄清这一点
并不希望有人看了这调侃后真的养成了FREE前都清0一下的习惯这是完全没必要的
更重要的是在通常的内存管理机制中使用FREE是不需要知道该块的大小的而清0则需要
如果执意要这样会影响到算法的设计甚至可能因为使用的静态大小并不是实际的动态结构大小而引入新的漏洞

xqterry · 发表于 2016-9-1 01:19

应该没有free时自己清零的内存管理实现一般都是分配后由调用者自己决定是否初始化内容 memset或者calloc 这个锅不应该堆内存管理实现来背

		自动登录	找回密码
密码			立即注册

[PSVita] xyz 新文章解释了 PS Vita 首个公开的内核漏洞的原理