标题 | 简介 | 类型 | 公开时间 | ||||||||||
|
|||||||||||||
|
|||||||||||||
详情 | |||||||||||||
[SAFE-ID: JIWO-2024-1351] 作者: ecawen 发表于: [2018-02-15]
本文共 [413] 位读者顶过
0x01、泄露危害: [出自:jiwo.org] iPhone‘s operating system on GitHub 黑客和安全研究者会很快找出越狱漏洞,苹果传统上一直非常不愿意向公众发布代码,尽管近年来已经使得iOS和MacOS的某些部分成为开源代码。但它已经特别注意保持iBoot的安全性和其代码的私密性;如果通过其赏金计划向苹果公司报告,引导过程中的错误是最有价值的,最高金额为20万美元。 0x02、事件处理: 在这个故事发布几个小时后,苹果公司发出了DMCA法律声明,要求GitHub取下iBoot代码。“iBoot”源代码是专有的,它包含了苹果公司的版权声明,不是开源的。“这样,苹果间接证实了代码是真实的。GitHub不久之后就取消了这个代码 0x03、什么是iBoot: iBoot它是iOS的一部分,负责确保操作系统的受信任的引导。换句话说,这是加载iOS的程序,这是开启iPhone时运行的第一个进程。它加载并验证内核是否被苹果正确签名,然后执行- 就像iPhone的BIOS一样。 0x04、影响版本: 该代码表示,它适用于操作系统的较早版本的iOS 9,但部分代码仍可能仍在iOS 11中使用。 0x05、安全反思: 从事件描述中发现,apple安全部门是没有github监控的,github泄露后,很多用户会大量复制,泄露范围就无法控制。那么做为源代码控制最后一道关卡,建议还要有一套gitbub监控系统,当然需要在源代码生命周期管理的各个环节都要对其进行有效的管理。 核心源代码建议要有一定的防止反编译的措施,针对于研发部门要严格控制核心代码gitlab的权限(只有开发者和主管有相应的访问权限),在source code review过程中也要严格控制。合并代码到master后,进入到部署环节后,对运维团队也要严格控制,如果不是频繁部署的代码,建议研发人员自己部署。出现bug调试的时候,建议开启dedug模式,不要在生产环境上源码调试。等等。。。 |